Skip to main content

How I build

Six decisions, and what each one cost me.

Anyone can list technologies. Here are the calls I make on every project, what I gave up to make them, and the one I’d change. A list of choices with no trade-offs isn’t engineering, it’s shopping.

No technical background needed for any of this. If you have one, there’s a version with the mechanisms left in, linked at the bottom.

Decision one

Signing in proves who you are. It never decides what you’re allowed to do.

When you sign in, the app gives your browser a ticket that says who you are. It does not write your permissions onto that ticket. What you’re allowed to do is looked up fresh, from the database, every single time you ask the server for anything.

A lot of software does the opposite, because it’s faster: put the permissions on the ticket and read them back. The problem shows up the day somebody leaves. You remove their access, and their ticket carries on saying otherwise until it expires. For hours, maybe, they can still do things they’re no longer allowed to do.

What it costs

An extra database lookup on every request, forever, and I had to make that lookup fast enough not to matter.

Why I pay it

Revoke someone at two o’clock and they’re out at two o’clock. In a system holding health information that isn’t a nice-to-have.

Decision two

Write down who did what, before anyone asks.

Every meaningful action gets recorded permanently: who, what, when. The record can’t be edited afterwards, including by me. A lot of software writes that record afterwards, on its own time. Mine writes it in the same breath as the change itself, so there is never a moment where the change has happened and the record of it hasn’t.

Why — I own compliance at my day job, so I know what the week before an inspection looks like when nobody wrote anything down. It looks like three people and a shared drive at eleven at night.

What it costs

More storage, more moving parts, and nothing the customer can see on launch day. Plus the honest cost: the record is written before you get your answer, so the writing is on your time rather than a background worker’s, and I had to make it fast enough that nobody notices. There’s also a genuine problem when someone exercises their right to have their data deleted — “it’s permanent” is not a legal defence — so I built the eraser too.

Why I pay it

The day someone asks “who changed this?”, you either have the answer or you don’t. There is no way to start keeping the record retroactively.

Decision three

The screen is not the security, and the live feed follows the same rules as the front door.

Hiding a button is a courtesy, not a control. Every rule is enforced on the server. And apps have two ways of giving you information. You ask for it by opening a page, or it arrives on its own, pushed to your screen as things happen. Live updates are lovely, and they’re a second door into the same building. Both doors get the same rule.

Why — Because I once got this wrong, in my own code. Everywhere you could ask for someone’s location, the app checked whether you were allowed to see it. On the live map, the check was wired to the wrong permission, so it sent everyone’s coordinates to people cleared to see only their own. I found it myself, fixed it, and wrote the whole thing up on this site — the mechanism, who it reached, and what it cost me to be sure it stays shut.

The full write-up

What it costs

The same rule now has to be expressed in more than one place, which means it has to be tested in more than one place. The live parts of the app are more work to build, because every push has to answer the same question as every page.

Why I pay it

One rule about who may see what, instead of two that are supposed to agree. And there’s a test that fails if anyone ever separates them again.

Decision four

Everyone gets the smallest amount of access that lets them do their job.

Not the access that’s convenient, not the access their manager has. The minimum. And you can only hand out access you hold yourself, so nobody can promote themselves — including the person setting up the roles.

What it costs

More setup, and occasional friction where somebody has to ask for something they could otherwise have taken.

Why I pay it

In my experience the damage doesn’t come from a stranger picking a lock. It comes from an ordinary account that could reach much further than it needed to.

Decision five

I pick boring tools on purpose.

C# and TypeScript for almost everything, one real database underneath, one cloud rather than three. Not whatever’s trending this year. Strict languages, because they catch a whole category of mistake before a person ever sees the screen. On a one-person team the computer has to be my second pair of eyes.

What it costs

I’m not on the interesting edge. I write a few more lines than a newer tool would need, and I’m not going to be the most exciting engineer in your interview loop.

Why I pay it

I’m often the only person who can fix this at two in the morning in two years’ time. “The answer is somewhere in a chat thread” isn’t a support plan. Boring also means the next person can pick it up, including the next person after me.

Decision six

If it isn’t automatic, it won’t happen.

I don’t release software by hand. I finish a change, it runs through 652 automated tests, and if they pass it goes live on its own. No checklist, no maintenance window, no me copying files onto a server at midnight.

What it costs

You have to build the machinery before you get any benefit from it. And you have to keep the tests honest, because they’re the only thing standing between a mistake and a real person. Automatic deployment with weak tests is just a faster way to break things in public. So I spend real time on the thing that ships the software instead of on the software.

Why I pay it

Manual steps get skipped at nine on a Friday, which is exactly when you need them not to be. And it means I ship small changes often instead of big changes rarely, which is the only version of this job I’ve found that isn’t frightening.

The list, since you’re here

What it’s all actually made of.

Every one of those is a tool I’ve shipped something real with and then had to keep running. There’s a longer and considerably less polite breakdown on the engineering page.

The pages you’re looking at
Angular and TypeScript, built once into ordinary files that a small web server, nginx, hands straight to your browser
The server
C# on .NET, with Entity Framework Core translating between the code and the database, plus Python, Go and Node where the job called for them
The database
PostgreSQL. Every change to its shape is versioned, so any copy of the app can bring itself up to date
Sign-in
Google only. No passwords stored here, because there are no passwords here. An administrator can end somebody’s sessions everywhere, immediately
Live updates
SignalR, so screens refresh themselves instead of you pressing reload
Packaging and hosting
Docker, and one file that brings the whole thing up on a laptop. In production, Amazon Web Services, described in Terraform files so it can be rebuilt from scratch
Tests and releases
GitHub Actions runs the tests and does the deploy, and nothing in it holds a permanent key to my cloud account
AI
Swappable providers: Claude, OpenAI, Google Gemini, and a built-in stand-in for when no key is configured

What each of those actually looks like

Five things, in the order they usually happen.

Learn your business first.

What that actually looks like

I come in and watch how the work actually gets done. The spreadsheet somebody rebuilds by hand every Friday. The whiteboard nobody is allowed to erase. The one step only one person knows. Then I build a system shaped around that, instead of a general tool you have to bend the business around. AI takes the drudgery — the retyping, the chasing, the sorting. What lived in five places lives in one. You can buy a version of this that ends in a slide deck. Mine ends in software your staff are using.

Build it.

Then I actually build it. I design the system, write it, and put it in front of your people. The screens they use, the server behind them, the database underneath, and the cloud it all sits on. Client records, scheduling, billing prep, who’s allowed to see what. The unglamorous software a business lives inside all day.

Two things, and they’re part of the build rather than a favour at the end. Written documentation, in plain language and to the standard a large company would expect. How it works, where it lives, what to do when it misbehaves. I document as much as a project allows, because the notes are what you’re left holding. And hands-on training with the people who’ll use it every day, on their own work, until they can get through a normal day without me. Software nobody was taught to use quietly turns back into spreadsheets.

Keep it running.

Software isn’t finished when it ships; that’s when it starts costing you. I do the boring half. Backups, upgrades, releases, the call at nine at night, the thing that broke because a vendor changed something and didn’t tell anyone. Every change I make is tested by machine on its way to being live, so “quick fix” doesn’t turn into a bad evening.

Prove it.

An auditor, an insurer or a state inspector asks you to show what happened and who did it. The system answers. It started keeping that record in the first week, not the week you got the letter. I own compliance at my day job, so I build for the day of the inspection.

Money, before you spend an hour of your week finding out: I quote a fixed price, and I quote it after the first visit rather than down the phone. I don’t publish a figure, because the honest one depends on what the work turns out to be — and I would rather give you a real number once I’ve seen the job than a comfortable one before. What the price buys is yours outright, and you can take it elsewhere without asking me.

That is the bespoke operational-software work described on this page. The defined local-business website package has a published scope and price. See the website package.

If you don’t know what to ask for yet

Most of this job is watching. The rest is building what I saw.

I come in, learn how the work actually gets done, and build one system around it. You end up holding the system, not a plan for one.

Every business I’ve worked inside had two versions of its process: the one in the handbook and the one that actually happens. The second one is the real one, and it’s usually held together by five or six things that don’t talk to each other. A scheduling spreadsheet. A shared inbox. A paper form somebody scans. A whiteboard. And one person keeping the rest of it in their head. None of that is bad management. Every one of those was a sensible decision at the time.

So the first part of this isn’t building anything. I come and watch the work, and ask a lot of dull questions. What gets typed twice? What does everybody quietly work around? Where does the week actually go? The answers are usually where the real system is.

How long that takes depends entirely on how big the operation is, and it isn’t something I’ll guess at down the phone. After the first visit I’ll tell you how long the watching runs, how long the build runs, and what the whole thing costs, as one fixed price.

Distance isn’t a filter. I’ll travel anywhere for this — Hillsboro is where I live, not the edge of the map. If you’re reading this from the other side of the state, or the other side of the country, you are still a customer.

What I write down is yours either way. If we do this part and you decide not to build anything — or to build it with somebody else — you keep it. It’s a description of how your own business actually works, and I was never selling you that.

Then I build one system for what I found, shaped to your trade rather than a software company’s idea of your trade. Your words on the screens. Your steps, in your order. Taking on a new customer, the schedule, the records, getting the invoices ready, and the numbers you keep having to ask somebody for. One place instead of five.

AI does the parts that are pure drudgery. The word gets used to mean anything, so here is exactly which parts:

  • Reading a stack of documents and pulling out the handful of details somebody would otherwise retype.
  • Writing the first draft of the note, so a person is correcting instead of composing.
  • Sorting the pile, so the urgent thing is at the top of it in the morning.
  • Noticing that this week doesn’t look like last week, before anybody has had time to notice it themselves.
  • And what it doesn’t do: decide anything that matters. A person still signs off, because a person is who your client, your insurer and the state come to.

One sign-in, one search, one straight answer, instead of four people checking four systems and hoping they agree. And when it’s live, I’m the one who keeps it running.

I’ve done this once, all the way through, and it has run the whole operation since 2023 — Pelican, the healthcare operations platform on the work page. That’s the whole track record: one, done properly, still running. I had an advantage there, and I’d rather say it than have you spot it: I worked inside that company, so nobody had to explain the day to me. For a client, that’s what the watching is for.

Pelican is also where I learned how careful the AI half has to be. It reads a referral document into the intake form. It drafts a care protocol from a plain description, for a nurse to correct. It turns “who deleted clients last week” into a filter an administrator can apply. It explains in ordinary words why somebody can or cannot do a thing, and shows what a proposed change to their access would reach before anybody makes it. And it takes dictation, so staff aren’t typing.

Not one of those acts on its own. It never runs the query — it hands the administrator a filter. It never changes anybody’s permissions — it shows what would change if you did. It writes the draft and a person signs it. In healthcare that restraint is the whole feature: anything clever enough to edit the record quietly is a liability, not a saving.

If you want to hear it from them rather than from me, ask on the call and I’ll arrange it — they’ll act as a reference on request. There’s no testimonial printed here, because I’m not going to write one on their behalf and put quote marks round it.

There isn’t a size of operation I’d turn away, and the one I run now is a whole company’s working day. What I do have is a queue rather than a ceiling: I’m one person, so I take one of these at a time, and what I can’t do is two at once. Ask me on the call where the queue is, and I’ll tell you before you book rather than in a month.

Bring the spreadsheet. It tells me more about your business than an org chart does.

The one I’ve already done this to


Documentation and training

The part where I make myself unnecessary.

Not because I’m going anywhere. Because software only one person understands isn’t finished.

Every company I’ve worked in has at least one system that only works because one particular person knows how to make it work. When that person is on holiday, so is the system.

I’ve been that person. It’s a bad position for a company and a worse one for the person in it. You can’t take a week off without your phone, and every question comes to you because there’s nowhere else for it to go. I’m not willing to be that person for you, and I’m not willing to hand you software that needs one.

Building the thing is half the job. The other half is making sure the people using it understand it. Three things come with anything I build, and none of them are extras.

The written version

how it works, where it lives, what it connects to, and what to do when it misbehaves on a Sunday morning. Written for whoever has to fix it, which might not be me. Plain language, and to the standard a large company would expect of its own. I document as much as the work allows, and I’d rather write down too much than leave you guessing.

Training on their own work

the people who’ll actually use it, on the jobs they do anyway, in the software they’ll open every morning. Not a recorded webinar everybody clicks through. I keep going until the questions stop, and I write the questions down, because a question is usually a design note in disguise.

And the notes keep up

when I change the software, I change the notes the same week. Documentation a year out of date is worse than none, because people still trust it. Kept current, it’s what the person you hire next year reads instead of waiting on my calendar.

There’s a compliance reason too, and it’s the one that saves money. An inspector doesn’t only want the system to be right. They want the written procedure, and evidence that your staff were trained on it. If that already exists, that part of an inspection stops being a project and becomes a filing question.

And the honest test of whether I did this part properly is whether you could replace me. I’d rather you never wanted to. You should always be able to.

So who owns it? You do — the code, the data, the documentation, all of it, outright. You can hand the lot to another developer tomorrow and you don’t need my permission or my blessing to do it. It isn’t a licence and there’s nothing to renew.

That answer is for the bespoke operational software described here. The defined website package has its own source-export and monthly hosting terms, published before you book a call.

And if I’m ever not available, what stands behind you is people rather than paperwork. There are people I’d hand this to, and they’re people I know rather than a name in an escrow clause. The written version is what turns that handover into a week instead of a rebuild, which is the real reason I’m strict about keeping it current.

Read a documentation set I wrote

A real one, start to finish, for a bakery chain I made up — the manual and the training plan, whole.

Ask what you’d actually be handed

Questions

Ask me the awkward one.

If any of these decisions looks wrong to you, that’s a good conversation and I’d like to have it. Every one of them has a cost written underneath it, and the cost is the part worth arguing with — tell me which one you’d have paid differently, and why.