SR&ED documentation as a solo founder: log technological uncertainty while you build

The SR&ED claim took me longer than the feature I was claiming for.

Not the form. The reconstruction. CRA wants the technological uncertainty documented: what you didn't know, what you tried, why the obvious approach failed. I had none of that written down. I had commits.

Rebuilding that narrative from about 14 months of git history and AI-assisted coding sessions took roughly three weeks I had not budgeted. This post is about the habit that would have made it a few days: a running log, two lines per dead end, written on the day the dead end happens.

Context, so you can weigh this properly. I'm the solo founder of CloudWise, an AWS cost optimization tool: 189 waste checks across 40+ AWS services, built by one person, pre-revenue, no paying customers. I paused feature development in August 2026 to work on distribution. I filed the SR&ED claim myself, without a consultant, and later received a CRA T2 notice of reassessment that resulted in a refund. I have filed exactly once. Everything below is one founder's experience, not advice on whether your work is eligible.

The problem: reconstructing SR&ED documentation after the fact

If you are mid-build, your record of the work is probably the same as mine was: a git log, some pull request descriptions, a ticket tracker, and a pile of chat sessions with an AI coding assistant.

That record answers one question well: what changed. It answers a different question badly: what did you not know at the time, and how did you find out.

A commit message like fix: handle untagged resources in attribution tells you a fix landed. It does not tell you whether that fix was the first approach or the fourth, why the earlier ones failed, or what each failure taught you. The failed approaches are often not in the history at all. They lived on a branch you deleted, or in a session you never saved, or only in your head.

So the three weeks were not writing time. They were archaeology: reading my own diffs in order, working out which ones marked a change of approach, then trying to recover why I had abandoned the previous one. Fourteen months later, the why is the part that has decayed the most.

What CRA actually asks you to document on the T661

I am going to stay close to the source here, because this is the part where founder blog posts tend to freelance.

The claim form is the T661. Its project section asks, in order, for three things: the scientific or technological uncertainties you faced, the work you did to try to overcome them, and the advancement you achieved or attempted. CRA's guide to Form T661 (T4088) walks through those lines and their word limits. The same guide has you indicate what supporting evidence exists for the work, and notes that you keep that evidence rather than submit it with the claim.

CRA's guidelines on the eligibility of work describe technological uncertainty as a situation where it is unknown whether, or how, a result can be achieved because the available technological knowledge is insufficient. The same page tells claimants to keep the evidence that is generated as the work progresses.

Read those two pages yourself before you read anyone's summary of them, including mine. They are shorter than you expect.

The practical consequence for technological uncertainty in an SR&ED claim is this: the form asks for a narrative with a specific shape. Uncertainty, then systematic work, then what was learned. A git log has a different shape. It is a list of things that worked well enough to commit.

What I had vs. what I needed

What the form asks about	What I had	What I needed
What was uncertain at the start	Nothing written. Memory.	A dated note stating what I did not know and why existing approaches did not settle it
What I tried, in order	Commits for the approaches that survived	A record of the approaches that did not survive, with the reason each was dropped
Why the obvious approach failed	Occasionally a PR description	One sentence, written the day it failed
What was learned	The final code	A plain statement of the conclusion, including "this does not work"
When the work happened	Commit timestamps	The same, which was the one thing git gave me for free

Timestamps were the only column where my existing record was enough. Everything else I rebuilt.

The AI-assisted coding sessions were the other source. Where a session survived, it sometimes held the reasoning I was missing, because I had explained the problem to the assistant in plain language before asking for help. But I had never kept them with this purpose in mind, so coverage was patchy and finding the relevant ones was slow.

One more thing I learned during the reconstruction: most of what I had built did not belong in the claim at all. Standard integration work, UI, and infrastructure plumbing did not qualify. What qualified was a narrow slice, cross-account cost attribution where tagging is incomplete and the answer has to be inferred, because that was where I did not know whether the approach would work. Sorting fourteen months of work into those two piles was part of the reconstruction. A log would have done that sorting for me as I went.

The lightweight SR&ED documentation habit: two lines per dead end

Here is the whole system. One file in the repo, docs/uncertainty-log.md, append-only. An entry only when an approach fails or you hit something you do not know how to do. Not a journal. Not a standup.

Each entry is two lines:

## 2026-03-14
Tried: inferring the owning account for untagged resources from the creating IAM principal.
Failed because: a shared deploy role creates resources for several accounts, so the principal does not identify the owner. Next: try usage-pattern correlation. (branch: attribution-v2, commit abc1234)

That entry is an illustration of the format in my problem area, not a record from my actual claim.

The rules I would follow:

Write it the day it fails. The reason is obvious today and gone in a month.
Line one is what you tried. Line two is why it failed and what that told you. If you cannot write line two, you have not understood the failure yet, which is worth knowing anyway.
Link the commit or branch. The log carries the reasoning, git carries the dates and the diffs. Together they cover each other's gaps.
Log the question before the answer. When you start on something you do not know how to do, write one line saying so. That line is the start of the narrative the form asks for.
Do not log routine work. If the path was known and it was just effort, it does not go in. This keeps the file short and gives you, or whoever prepares your claim, a first rough sort of uncertain work from routine work.
Save the AI sessions that contain reasoning. Export them into a folder next to the log, named by date. They are timestamped explanations of what you did not know, written at the time. I had these by accident. Have them on purpose.

Cost: a couple of minutes per dead end. I would have traded that for three weeks without thinking about it.

What I'd do differently

Start the log on day one of the build, not when I first hear the word SR&ED.
Stop deleting failed branches. Tag them and leave them. A failed approach with a commit history is evidence. A deleted one is an anecdote.
Write PR descriptions that say what was ruled out, not only what was done.
Read the T661 guide before the build, not after. Knowing the shape of the questions changes what you bother to write down.
Budget the time. Even with a good log, the claim is real work. Without one, it was three weeks.
Separate uncertain work from routine work as I go, because that line decided what went into the claim, and drawing it afterwards was slow.

What this post is not

I am a founder who filed once. I am not an SR&ED advisor, I cannot assess your work, and I cannot tell you whether you qualify. If you are a Canadian founder working on SR&ED for startups and you think some of your work involved real technological uncertainty, talk to a qualified claim preparer and read CRA's own pages linked above.

What I can tell you is narrower and I am confident in it: whatever you end up claiming, and whoever prepares it, the record you keep while building is the raw material. Two lines per dead end. Start today.

Rick Wise is the solo founder of CloudWise, an AWS cost optimization tool with 189 waste checks across 40+ AWS services. He filed one SR&ED claim, himself, and is not a tax advisor. He helps technical founders reconstruct the engineering narrative from their repo and AI coding sessions at SR&ED Lab. Your accountant or claim preparer still files.