What a non-engineer decides when shipping software

I am not an engineer. I have shipped two applications. Both are described, everywhere they appear, as designed and shipped with Claude Code, and the phrasing is deliberate. Claude Code wrote the implementation. I made every decision the code cannot make for itself, and those decisions turn out to be most of the work.

Here is the list, with the two products as examples: DrillCard, a browser-based incident-command drill app for fire and EMS departments, and Throughline, a novel-plotting web app for plotters and pantsers.

What to build, and for whom

No tool decides this, and most failed software fails here. DrillCard began with a gap any training chief can describe. Live-fire training is expensive, weather-dependent and rare. Tabletop drills are cheap, but nobody sweats. The decision was to build the thing in between: a drill a training chief can run this afternoon, with the department’s own stations and apparatus, and hand the chief a report on by dinner.

Throughline began with a different gap. Plotters want structure before they draft; pantsers want to discover it as they go. Most tools pick a side. The product decision was to serve both.

The form factor

Native app, web app, or something in between is a decision with a long tail: store accounts, review cycles, two codebases or one. For DrillCard the answer was browser-based, nothing to install. A company officer runs a drill from a phone in the bay, an evaluator watches from a laptop, and nobody clears an install with IT first. For Throughline, a writing tool used at a desk, a web app was the obvious call.

Getting this wrong is the most expensive mistake a non-engineer can make, because you find the ceiling after weeks of work instead of before.

The data path

Software is only as credible as the data under it. For DrillCard that meant real geography and the department’s real roster. A drill is set on a real address. Response times come from real drive times between the department’s own stations and the incident. Departments load their own stations, apparatus and crew sizes, so the drill dispatches the units they run. That was a product decision before it was a technical one, and it is the one that makes the app worth a training chief’s afternoon.

The build path, and its ceiling

Throughline is built on Lovable with Supabase behind it. I chose that path knowing where it stops: Lovable builds for the browser, so if Throughline ever needed to live in an app store it would need wrapping or a rebuild. For a writing tool used at a desk, that ceiling is not a wall I expect to hit, and the code can be exported and hosted elsewhere if it ever is.

Knowing the ceiling in advance is the whole trick. Every build path has one. The non-engineer’s job is to name it before the first screen exists, so the wall becomes a planned step instead of a crisis.

The spec, and what done means

Claude Code writes to a spec. The spec is mine. For DrillCard I wrote the product spec, designed the UI and the training logic, and made the architecture calls: how a unit moves from Dispatch through Arrival and Staging to Assigned and Closeout, what Mission Control shows the trainer, what the after-action report has to prove to a chief. Each of those is a decision a tool will make badly if a human leaves it open.

Done is also mine to define. Every release gets tested against the spec before it ships. The tool writes the code; I decide whether the code did what the drill needs.

Everything around the software

An app is not a product until the rest exists. For DrillCard that meant the brand identity, the website and the onboarding assets, a trademark filing and a patent application. None of it is code. All of it is the founder’s to do or to direct, and most of it was done before a department saw the app.

Where DrillCard is now

DrillCard is in beta with one department of 50+ stations. The venture started in October 2025. Trademark filed, patent pending. The department stays unnamed until it says otherwise, which is its own kind of decision.

The job title that fits

The non-engineer who ships software holds two jobs that already have names: product owner and editor. The product owner decides what gets built, for whom, in what form, on what data. The editor decides whether what came back meets the standard. Claude Code does the part in between, and the credit line should say so.