Old cabinetmakers finished the joints you would never see. The back of a drawer, the underside of a tabletop, the places a customer would never inspect got the same care as the polished front. The standard was held whether or not anyone was watching. There is a name for that ethic, and it is most of what we mean when we say built by craftsmen, not coders.
Software has hidden joints too. They are the parts no demo ever shows: error handling, logging, the seams between systems, the code paths that only run when something goes wrong. They are invisible on a good day, and they are the entire story on a bad one.
The demo lies by omission
Every piece of software looks fine in a demo, because a demo is the happy path. The data is clean, the network is up, the user does exactly what the presenter expects. Real use is not like that. Users paste in strange characters. Connections drop halfway through. Two people edit the same record at once. A file that was supposed to be there is not.
What the software does in those moments is decided long before they happen, in code you will never look at. A system built only for the happy path does not fail gracefully. It fails at 2 a.m., in a way nobody understands, with your data in the middle of it.
What “finished” looks like behind the wall
When we say a project is finished, we mean the hidden parts are finished too. In practice that means things like:
- Errors are caught, explained, and logged, not swallowed in silence.
- When something fails, the system fails safely and tells someone, rather than corrupting data and moving on.
- There is a record of what happened, so a problem can be diagnosed instead of guessed at.
- The edge cases, the empty states, and the “this should never happen” paths are actually handled.
- The code is written to be read by the next person, because there is always a next person.
None of this shows up in a screenshot. All of it decides whether your software is a relief or a liability when it matters.
Hidden shortcuts are borrowed time
Skipping the hidden work is the most tempting shortcut in software, because it is invisible and it makes the demo come faster. It is also borrowed time at a bad interest rate. The cut corner does not disappear. It waits. It becomes the outage during your busiest week, the data loss you cannot explain to your board, the bug that takes three days to find because nothing was logged.
This is what people mean, loosely, by technical debt. We prefer the plainer framing: unfinished work that someone will pay for later, usually the client, usually at the worst possible time. Finishing the hidden joints now is cheaper than paying that bill in an emergency.
The standard held when no one is watching
There is a deeper reason we build this way, and we do not hide it. Our standards are rooted in the conviction that the whole of the work matters, seen or unseen, because the work is offered to more than the client. You do not have to share that conviction to benefit from it. The quality is the proof, and it shows up in the same place the old craftsmen’s did: in the parts you were never going to check.
Finished work is finished, including the parts no one will see. That is not a marketing line for us. It is the thing that keeps your software standing on the day it is tested.
Written by
Miles Bassett
Founder and principal craftsman at Prairie Code. He writes and speaks on deliberate AI adoption for small businesses and institutions.