You already have a websitea prototypea spreadsheetan ideaa website. It needs to become software.

You have an idea, and no idea where to start.

You know what it should do. You’ve explained it to friends, maybe drawn it on something. What you don’t have is a way to turn that into a thing people can use, and every route you’ve looked at wants you to already know the answers: which stack, which features first, what it costs.

You don’t need to know any of that first. Bring the idea in your own words and the first job is ours: turning it into a plan you can read. What it has to do on day one, what can wait, what the first version would cost. Nothing gets built until you’ve seen that and agreed to it.

Then the first version is small on purpose. It does the one thing the idea is for, real people use it, and what they do decides what comes next. Most ideas don’t need everything on the napkin to prove they work. They need the part that matters, built well, in front of someone.

You built it with AI. Now it has to be real.

You built it in a weekend, or a month, with a tool that writes code faster than anyone can read it. Then one day a customer saw another customer’s data, or the bill doubled, or a one-line change broke three things you didn’t touch. Or nothing has happened yet, and you’d like to keep it that way.

None of that means it’s bad. It was built to prove something, and it did. Making it real is a different job: a deploy that stays up, security you can put strangers on, and code someone who isn’t you could maintain.

So it starts with an audit, not a rewrite. We read the whole codebase and write you a verdict: harden it, rewrite part of it, or rewrite it, and what each road would cost. Nobody touches the code before you have it, and the verdict is yours to keep whether or not we do the work.

Most of the time the verdict lands in the middle. The product stays, the parts that would have hurt you get replaced, and the engineering is scoped from what we found, not from a guess.

Your website needs to do more than it was built for.

A website tells people what you do. At some point it has to start doing some of it. Customers log in to see their orders and their invoices. Staff run the day from one screen instead of four tabs and a spreadsheet. A booking made at 9pm is in the calendar, the inventory, and the books by 9:01, and nobody typed it in twice.

That’s what a web app is: a customer portal, a back office for your staff, the connection between the front of the business and the back. If no customer ever sees it, it’s an internal tool, and it’s the same work. It goes beside the site you already have, whoever built it, or stands on its own until there’s a site to stand beside.

Here’s the part that usually gets skipped. The people who use a back office can’t choose a different one, so the small things decide whether it gets used or worked around: a search that answers as you type, charts that don’t lie about their axes, a list that never loses your place, everything reachable from the keyboard. None of that is hard, but it has to be somebody’s job, and it’s the difference between software your staff tolerate and software they stop noticing.

What does an engagement look like?

It starts with the brief, or with the audit if you’re bringing us a codebase. On the call we agree what we’re building, what we’re not, and what it costs, all of it in writing before anything starts. Then it ships in increments you can actually use, the first in weeks, not months.

When it launches, you choose where it lives. We can host it and keep it running, or you can take it in-house: the code is yours the whole time, and it comes with the documentation your team needs to run it without us.

Sometimes what you need first is a decision rather than code, a rewrite call or a second opinion on an estimate. That’s a shorter engagement, and we take those too. Web app and software engagements start around $10k. If your budget is smaller than that, send the brief anyway and we’ll tell you honestly if it’s a fit.