Rebuilding a Small Software Claim Around Failed Builds

The situation

Besnik's question, when he first sat down with us, was almost exactly this: why does the government keep saying my coding work does not count, when I spent nights and weekends on it and it clearly did not work the first five times I tried? He had a right to be confused. He had asked something close to that same question two years earlier, after his first research and development claim was denied, and he had been told then that the problem was documentation, not the underlying work. He had gone away, tried to fix it, filed a second claim, and been denied again for what looked to him like the same reason.

Besnik worked gig shifts, picking up short-term software contracts and app-building projects between longer stretches of unrelated freelance work. Alongside that, he and his brother Arben, who worked full time at a call centre, had been building a scheduling app aimed at small trades businesses, the kind of tool that would let a two-person plumbing outfit manage jobs without an expensive commercial platform. A friend, Mohamud, who worked as a dental assistant, had joined the project informally, contributing testing and some interface work in his spare time. None of the three treated the work as a formal company; it was closer to a shared obsession they chipped away at after their day jobs ended, fuelled by the belief that the app could eventually become a real product.

The claim was small by any measure, sitting under fifteen thousand dollars, but for Besnik it mattered. He had built the project around the belief that the credit would offset some of the unpaid hours he and his collaborators had put in trying to solve a scheduling-conflict algorithm that kept producing double-bookings under certain conditions. When the second denial arrived, the reviewer's notes said essentially what the first denial had said: the narrative described what the software eventually did, not what problem the team had been trying to solve or what approaches had failed along the way.

Besnik brought both denial letters to our first meeting, along with a folder of half-organized notes, and asked us plainly to explain what he was doing wrong, because from where he sat, the second attempt looked like a genuine improvement on the first, and he could not understand what more the reviewer could possibly have wanted from him. He had rewritten the whole narrative, added detail, and still landed on the same result, which felt to him less like a fixable error and more like a door that simply would not open.

Why this was harder than it looked

A research and development claim under the federal tax credit program is not a reward for building working software. It is a reward for a documented process of technological uncertainty, meaning the team did not know in advance how to solve a problem, tried an approach, and had to work through failures or unexpected results to get to an answer, if they got to one at all. The credit exists to support that kind of investigative work, not the ordinary business of writing code that eventually functions.

Besnik's first claim had described the finished scheduling algorithm and asserted, in general terms, that developing it had involved technological challenges. That is a common mistake, and it is exactly the kind of claim reviewers are trained to reject, because a description of a finished product does not show any uncertainty or investigation. It shows a result.

His second claim was better, but it made a different version of the same error. Besnik had gone back after the algorithm was finished and written up, from memory, an account of the difficulties the team had supposedly faced along the way. It read more convincingly than the first attempt, but it had been written after the fact, months after the actual coding sessions, and it did not match anything that had been recorded contemporaneously, because nothing had been recorded contemporaneously. There were no dated notes, no failed build logs, no record of an approach being tried and abandoned before a different one was tried instead. A reviewer reading a narrative reconstructed from memory, with no supporting record created at the time, has good reason to treat it with skepticism, and that is what happened.

The harder part, for Besnik personally, was that this was not his first time hearing this feedback. We were direct with him that the advice given after the first denial had been essentially correct, and that the second claim's shortcomings were a variation on the same theme rather than a new problem. He had not ignored the advice out of carelessness. He had misunderstood what contemporaneous documentation actually meant, believing that writing a more detailed account, even after the fact, would satisfy the requirement. It would not, and could not, no matter how much effort or honesty went into reconstructing it, because the whole point of the requirement is to distinguish a record made while the uncertainty was live from a story told once the answer was already known.

What we did

1. Reviewed both denial letters side by side with Besnik to show him precisely how the second claim had repeated the first claim's core defect, since he needed to understand the actual pattern before any rebuilt claim could avoid making the same mistake a third time, and seeing both letters together made the repetition obvious in a way neither letter alone had. Besnik had read each one in isolation, months apart, and had never laid them side by side to see how closely the second reviewer's concerns tracked the first.
2. Asked Besnik, Arben and Mohamud to gather anything created during development, including old chat messages, code repository commit histories, and any dated files, because even informal records made at the time carry weight that a polished after-the-fact narrative does not, and we specifically asked them not to clean anything up or tidy the commit history before showing it to us, since the messy version was the one that could actually be verified.
3. Found usable contemporaneous evidence in the code repository's commit log, which showed dated attempts at the scheduling algorithm, including several commits that were later reverted, giving us a genuine timestamped record of approaches being tried and abandoned, which was the single most valuable piece of evidence in the entire file once we found it, because unlike Besnik's memory it could not be argued with.
4. Rebuilt the technical narrative around that commit history rather than around Besnik's memory of events, describing specific failed approaches, what made each one fail, and what was tried next, so the claim reflected an investigative process instead of a finished result, matching each reverted commit to the technical reason it had been abandoned wherever the code itself made that reason clear.
5. Narrowed the claim substantially to cover only the period and the specific algorithm work supported by the commit evidence, cutting out broader work on the app's interface and other features that had no comparable documentation trail behind them, even though that work had taken real time and mattered to the finished product, because filing for work we could not evidence would have risked the credibility of the whole claim.
6. Prepared Besnik for a reduced claim before filing, explaining that the evidence only supported a fraction of what he had originally claimed, and that the honest, defensible number was well below what he had hoped for on either of his first two attempts, a conversation we had before filing rather than after, so the result would not come as a fresh disappointment.
7. Filed the narrowed claim with the commit history as a supporting exhibit, framing it explicitly as a technological uncertainty case tied to specific, dated evidence rather than a general assertion about the difficulty of the project, and inviting the reviewer to check the commit timestamps directly against the narrative we submitted, which gave the claim a verifiable backbone neither of Besnik's earlier attempts had offered.

The outcome

The rebuilt claim was smaller than either of Besnik's first two attempts, covering only the scheduling-algorithm work supported by the commit history, and it was allowed on that narrower basis. The interface and testing contributions from Arben and Mohamud, which had no comparable dated record, were left out of the claim entirely, since there was nothing to support treating them as documented technological uncertainty rather than ordinary development work, however much genuine effort had gone into it.

Most of what Besnik had originally hoped to claim across his three attempts still did not survive, and we told him plainly that this was the realistic ceiling given what could actually be documented after the fact. The amount ultimately allowed was a modest fraction of the total time the team had put into the project, and it did not come close to compensating for the unpaid hours Besnik had originally hoped the credit would offset. Arben and Mohamud, hearing the final number, were disappointed but not surprised, since by that point all three had absorbed the same lesson about what the claim could and could not reach.

What changed going forward was Besnik's approach to documentation itself. He set up a simple habit, at Arben's suggestion, of writing a short dated note each time an approach was tried and abandoned on any future project, treating it as part of the work rather than paperwork to be done later. Besnik told us afterward that the smaller, successful claim felt less satisfying than a bigger number would have, but that it was the first time in three attempts he had understood exactly why a claim did or did not hold up. That understanding, more than the modest amount ultimately allowed, was what he said he would carry into the next project, whether or not it ever produced another claim.

What you can learn from this