There was a week where I did not ship a single feature. I read legislation instead. It felt, at the time, like the least productive week I had had in months. It was probably the most useful.
The assumption that started it
I had built a signing flow. It worked. It was clean, it looked good, and I was quietly proud of it. Then somebody asked me a question I could not answer: are there documents this should refuse to handle?
I did not know. I had built the feature on a general sense that electronic signatures were fine in South Africa, which is the kind of belief that survives right up until the moment it matters.
So I went and read the act. Not a summary of the act. The act.
What reading it actually changed
Two things, and only one of them was a code change.
The code change was small. A handful of document types genuinely sit outside what an ordinary electronic signature can do, and the honest product behaviour is to say so plainly rather than let someone sign something that will not hold. That is an afternoon of work once you know.
The second change was bigger and had nothing to do with the product. I stopped trusting my summaries. I had a whole shelf of confident beliefs about how things work here, absorbed from blog posts and half-remembered conversations and other people's marketing. Some of them were right. Enough of them were wrong that I could no longer tell which was which without checking.
That is an uncomfortable position to be in when you are selling systems to people who will rely on them.
Why this is a competitive thing, not just a diligent thing
Here is what I did not expect.
Almost nobody does this. The market is full of tools built somewhere else and pointed at South Africa afterwards, with the local rules bolted on later by someone reading the same blog posts I was. When you actually go to the primary source, you end up knowing things your competitors are guessing at, and that shows up in the product as small, specific behaviours that feel obvious once they exist and are invisible until they do.
It also shows up in how you sell. You stop making claims you cannot support. You start being able to answer the awkward question in the room instead of promising to come back on it. Clients notice that faster than they notice features.
The part I keep having to relearn
Reading the source is slow, boring, and produces nothing you can screenshot. There is no demo. There is no changelog entry that says "read the VAT Act". Every incentive I have points at shipping something visible instead.
And the work compounds anyway. Every piece of primary material I read makes the next one faster, because the structure repeats and the vocabulary stops being foreign. The first one took a week. They do not take a week anymore.
I think this is the same trap as building before speaking to customers, which I have written about before. Both feel like the responsible thing. Both are ways of avoiding the slower activity that would tell you whether you are right.
What I would tell someone building for a specific market
Pick the two or three rules your product actually touches, and go and read them yourself, in full, from the source that issues them. Not a summary. Not a competitor's landing page. Not a chatbot's confident paragraph, mine included.
You will find at least one thing you had wrong. That thing is the reason to do it.
Frequently Asked Questions
Why read legislation instead of a summary? Summaries are someone else's interpretation, and you inherit their errors without knowing which ones they are. Reading the source is slower once and faster forever, because you stop having to check whether the summary you are using is the good one.
Did reading it change the product much? Less than I expected. It changed one flow and a handful of edge cases. What it really changed was how confidently I could answer questions, and how many claims I stopped making.
Is this not just a job for a lawyer? A lawyer is who you go to for advice on your position, and you should. But if you are building the system that has to behave correctly, you need to understand the rule yourself, because the person writing the code is the person encoding the assumption.
How do you find the time? I stopped treating it as overhead and started treating it as product work, because that is what it is. The week I did not ship anything visible was a week spent removing wrong assumptions from everything I shipped afterwards.
More of the build in building NexCRM, what I got wrong first, and the version of this same trap I fell into earlier in I built my business backwards. More of the journey at heinoux.nexbdm.co.za.