Custom web development
For businesses that already have clients.
Most people who ask me for custom development need one custom piece bolted onto standard parts, not a custom system. The difference between those two is several times the price, and years of who has to maintain it.
What you get
- A written scope before anything is built, with the parts I recommend renting rather than building named explicitly and priced at zero
- Standard parts wherever standard parts work: Next.js, PostgreSQL, an existing payment provider, an existing auth provider. Custom code only where custom is the point
- One piece at a time, working. The first useful thing ships before the second one starts
- Documentation written for the next developer, not for me: data model, decisions and why, failure modes, how to run it
- Code in your repository, accounts in your name, and no part of it that only works while you pay me
Audit delivered in 5 working days
The written plan lands 2 working days after that. Scope and price are fixed and agreed before any build starts, so nothing appears on a later invoice that you did not sign off.
How it runs
- 5 working daysAuditI go through your site, funnel, booking, CRM and backend, and find where the friction and the leaks are.
- 2 working daysPlanA written breakdown of what works, what is costing you, and what to fix first. In order, with reasons.
- 2 to 6 weeksRebuildI fix or rebuild the parts that need it: site, client flow, intake, automation, backend. Scoped and priced before it starts, with 30 days of changes included.
- 2 monthsWarrantyIf something I built breaks in the first two months, I fix it. No ticket, no invoice, no argument about whose fault it is.
- Monthly, optionalSupportAfter the warranty ends I stay on to maintain and improve it, if you want me to.
So before I quote anything, I tell you which one you are.
How to tell which one you are
Four questions. Answer them honestly and you will usually know before we speak.
Does an off-the-shelf tool do 80% of it? If yes, the right build is the missing 20%, connected properly. Rebuilding the 80% you could have rented is the most common and most expensive mistake in this category.
Is the thing you need actually unusual, or just yours? Booking, invoicing, client portals, forms, dashboards. These feel specific because they are yours. They are not unusual, and something already does them.
Would a competitor's version work if you changed the logo? If yes, you are buying configuration, not development.
Is the custom part where you make money, or where you spend time? Building custom around how you earn is usually worth it. Building custom around admin almost never is, because admin should be shrinking, not being enshrined in code.
If you answered no to the first three and "where I make money" to the fourth, you have a genuine case. That is roughly one in four of the inquiries I get for this.
When custom is genuinely right
Your process is the product.If how you do the work is why clients choose you, software that forces you into someone else's process costs you the thing you sell.
The integration does not exist. Two systems that have to talk, and nothing off the shelf connects them. This is the most common real case, and it is usually smaller than people expect.
Volume broke the tool. What worked at 50 clients falls over at 500. Sometimes that is a bigger plan on the same tool. Sometimes it is not.
The data cannot leave. Contractual or regulatory reasons why it has to run on infrastructure you control. Rare, and absolute when it applies.
Turnaround, stated
| Stage | Time |
|---|---|
| Audit and scope | 5 working days |
| Plan, with what to rent named | 2 working days |
| First working piece | 2 to 3 weeks |
| Changes after launch | 30 days included |
| Warranty | 2 months. If something I built breaks, I fix it |
The cost nobody quotes: owning it
A custom system has a permanent cost that never appears in a quote. Somebody has to understand it, forever.
Rented software is maintained by the company that sells it. Custom software is maintained by whoever you can find, using whatever documentation exists. If that documentation does not exist, the second developer rewrites rather than reads, and you pay for the same thing twice.
This is the real argument for building less. Every custom piece is a permanent liability as well as an asset, and the liability does not show up until the person who built it is unavailable.
Two consequences, and both are in how I work: the scope names what to rent, and the handover is written for someone who is not me.
Proof
I rebuilt matted.co.uk. Search Console impressions went from 0 to 46,800 in three months.
That was a rebuild rather than a custom system, and I am not going to stretch it into something it is not. What it demonstrates is the part that matters most here: the structure was the problem, and fixing structure is what produced the result. Custom development is the same discipline with higher stakes, because a badly structured custom system cannot be fixed by anyone but its author.
The most recent custom piece I built is smaller and more typical of what genuine custom looks like: a webhook route that verifies a signature, translates one service's format into another's, and posts it. Forty lines. Two automation platforms quoted a monthly subscription for the same job. That is the shape of most real custom work. Small, specific, and surrounded by standard parts.
What this is not
This is not a rebuild of software you already rent. If your CRM annoys you, the answer is almost never to build a CRM.
This is not an app. Mobile applications are a different discipline and I do not take that work.
This is not staff augmentation. I am not available as an extra pair of hands on someone else's project with someone else's architecture.