Custom software should be something you buy
Your team has a problem that software could solve. Not a famous problem, a specific one. The technicians' reports take the office hours to reformat and send. The same numbers get keyed into three systems by hand. The email thread is the process, and the process breaks every time someone's on holiday. You know exactly what would fix it. You just can't buy that fix anywhere.
That last sentence is why we started klair. So before any of the product, here is the thinking underneath it.
Today a team in that spot has three options, and we don't love any of them.
You can hire engineers. Sit through forty interviews to find two who can start in eight weeks, sign them to year-long contracts, and hope the thing you needed is still the thing you need by the time it ships.
You can hire an agency. Pay for a discovery phase that ends in a slide deck, a plan that pads every estimate, and a standing Thursday call where someone reads a status board out loud.
You can do it yourself. Block off Wednesday afternoons, wire up an AI tool, and watch the project stall in month four when it suggests a change nobody on the team can safely approve.
Look at the three and a pattern shows up. The one thing you cannot do is the obvious thing: buy it. You can buy a CRM. You can buy a payroll system, a help desk, an accounting package. Each has a price, a sign-up, a number you can reach on a Sunday night. The software your team actually needs, the one shaped around how you work, is the exception. You can hire it, outsource it, or build it yourself, but you can't walk up and purchase it. The vending-machine version, where you describe the problem and working software comes out, doesn't exist.
Custom software is the last thing in business you still can't simply buy.
That gap is the whole reason we're here. We thought it should close, so we set out to close it. The rest of this is what we decided that has to mean.
A workshop that doesn't close.
The first conviction is about time, and who has to spend it.
Picture a workshop that never shuts for the night. You sit down on a Tuesday afternoon: coffee, laptop, the problem you've been carrying for three weeks. You don't write a specification from scratch. You answer questions. What does this need to do? Who will use it? What must it never get wrong? What does a good Friday look like once it works? You answer, the workshop drafts the plan from your answers, you read it, you sign it.
Then you log off.
Through Tuesday night, Wednesday morning, your weekly all-hands, the school run, the call you couldn't move, the workshop runs. It plans. It builds. It checks its own work and tries again when something isn't right. Every step shows up in plain language a non-engineer can follow.
By Wednesday at 09:14 there's an ordered summary of everything done since you last looked, and a short queue of finished work waiting for you. Each piece comes with a note on what it does and what it might affect.
You read. You sign. The next milestone begins.
We kept coming back to one line while we built this. What builds your software no longer has to sleep. The accountability still does, and we think that part should never change.
Two human moments. Everything else is the workshop.
The second conviction is the one we'd defend hardest, because it's the structural choice that makes the first one safe.
You define what to build. You approve what ships. Between those two moments, the workshop runs on its own. You don't write the software. You don't test it. You don't manage it hour to hour. But the signature at the end isn't busywork. It's accountability, and it belongs to a named person on your side. Every time.
There is no "ship it without me" mode. Not as a setting, not as a premium tier, not as a favour for a trusted client. We won't build it. We've watched too many teams get burned by software that shipped with no human on the receiving end, and we'd rather lose the sale than remove the person at the boundary. That one is non-negotiable.
The engine that does the building works backstage. You don't have to know its name to use it. When you hire us, we run it for you.
What it looks like in the real world.
The reason this stays an essay and not a theory is that the everyday version is unglamorous, and that's the point.
Somewhere there's an office team that used to spend its afternoons turning raw field notes into clean, on-brand documents, by hand, every day. The work was careful and thankless and never going to end. Software does the formatting now, and a person signs off on the result before it goes out. The afternoons came back, and the same small team absorbs far more without drowning.
Somewhere else there are experts buried under documents to read, qualify, and structure before any of it can be used. An automation does the first heavy pass and hands them a clean draft. They spend their hours on judgment, which is the part only they can do, instead of on the formatting that was eating the day.
Different teams, same shape. Nobody hired an engineer, ran a six-month project, or changed the tools they already use. They described a problem. They got working software. That's the outcome we keep chasing, and the kind of ordinary win we'd take over a flashy demo any day.
Why we wrote this down.
We could have led with a feature list. We wrote this instead because the conviction came first and the product followed, not the other way around. Custom software should be something you buy. The thing that builds it can work around the clock, and a person you can name should still approve every change that ships. Hold those two together and you get the fourth option, the one that should have existed all along.
If your team has a problem software could solve, the door is open whenever you're ready. The convictions above are the part that won't change.
· · ·
— the klair founders