Custom Builds, Quoted Per Project

The usual trigger is a plugin that almost does it. It covers eighty per cent of what you need, the last twenty per cent is the part your business actually runs on, and the workaround has quietly become a person doing something by hand every week.

At that point a custom build is often cheaper than the stack of subscriptions holding the current one together, and it is certainly cheaper than the manual work. The test we apply is simple: if the thing you need is genuinely unusual, build it; if a template would do, we will tell you that instead.

You own the result. The code, the database and the deployment are yours at the end, and nothing is built to make leaving us expensive.

Most people arrive here because their site no longer matches the business behind it. It was right three years ago, or it was built from a theme that has been stretched in six directions since, and every new page makes the inconsistency more obvious.

A design system fixes that at the root rather than page by page. Decide the type scale, the colour, the spacing and the components once, and every page after it is assembled from parts that already agree with each other. New pages stop being design decisions.

The awkward part is usually the words. Design cannot fix copy that has not been decided, and we would rather say so at the start than lay out placeholder text and let you discover it at the end.

This is the work that starts with a spreadsheet. Someone built it years ago, it now runs a real part of the business, and it is emailed around, edited by four people and occasionally overwritten. Everyone knows it is fragile and nobody can be the one to stop using it.

Turning that into a real application is mostly about deciding what is actually true: who is allowed to change what, what happens when two people act at once, and what the records need to look like a year from now. The screens are the easy half.

Internal tools, customer portals, dashboards and staff systems all sit here. They are rarely glamorous and they are usually the thing that removes the most work from someone's week.

Selling online stops being simple the moment the product does. Subscriptions, mixed carts, per-jurisdiction tax, physical goods beside digital ones, a discount that has to apply to some of it — each is ordinary on its own, and together they are past what a hosted cart will do.

The money side is where care matters most. Card details go straight to Stripe or PayPal and never touch your server, which keeps you out of the heavier compliance obligations by design rather than by luck. This platform's own checkout is built exactly that way.

Tax is the part people underestimate. Rates differ by where the buyer is, not where you are, and getting it wrong is discovered late and corrected expensively.

Most AI features fail the same way: they sound confident and they are not connected to anything. A model that cannot read your actual records will produce a fluent answer about an order that does not exist, and one wrong answer in front of a customer undoes the other ninety-nine.

The work worth doing is the plumbing. Give the model real, permissioned access to your own data, constrain what it is allowed to do with it, and make it say it does not know rather than invent. That is less impressive in a demo and considerably more useful on a Tuesday.

We will also tell you when AI is the wrong answer. A great many requests that arrive as "can we add AI" are better solved by a report, a search box, or removing a step.

Recurring revenue is easy until a payment fails. Then the questions start: when do you retry, when do you email, when do you suspend, when do you give up, and who is doing all of that by hand right now.

Getting that ladder right is worth real money, because most cancelled subscriptions are not decisions — they are expired cards nobody chased. The unglamorous machinery of invoicing, reminders, grace periods and reinstatement is where the revenue actually leaks.

We run precisely this in production for our own product, which is where the detail comes from rather than from a specification somebody wrote once.

Two systems that will not talk to each other usually cost a person several hours a week, and that person is usually the one who can least afford it. The work is rarely difficult; it is fiddly, and it fails in ways that are hard to see.

The dangerous failure is not an error. It is a call that returns nothing and looks exactly like a legitimate empty result — no alarm, no log, just a system that quietly stops being correct. We have found published documentation pointing at hosts that no longer exist and auth schemes that were never right, and the only way to know is to run it against the live service.

So we verify against the real API rather than the docs, and build the checks that tell you when it stops working.

This is the work that is invisible until the week it is not. Patching, hardening, monitoring, certificate renewals and backups are all boring, and every one of them is on the list of things that take a business offline when skipped.

The most common gap we find is not a missing backup — it is a backup that has never been restored. An untested backup is a belief rather than a backup, and the moment you find that out is the worst possible moment to find it out.

The second most common is a scheduled job that has never once run. It appears in the list, it looks healthy, and nothing has ever checked that it actually executed.

If your invoices and password resets are landing in spam, everything downstream of them looks broken to your customers and fine to you. It is one of the few problems that is completely invisible from the inside.

The causes are usually mundane: SPF, DKIM and DMARC not set up, or set up years ago and no longer matching where mail is actually sent from. Add a sending domain with no reputation and message content that trips filters, and the mail simply stops arriving.

Worth knowing that this is measurable rather than a matter of opinion. Mail can be scored before it is sent, and the first time we ran that check on our own platform it found a defect present in every campaign it had ever produced.

Nobody enjoys a migration. They are usually forced — a platform being retired, a price rise, a vendor you no longer trust, or a system that cannot do the next thing you need.

The risk is almost never the data. It is the thousand small things attached to it: the URLs people have bookmarked, the search ranking built over years, the integrations pointing at the old place, and the customers midway through a subscription. Ranking you built over years should not die in an afternoon.

So the old platform stays live until the new one has proved itself under real traffic, and every old address goes somewhere sensible rather than to a 404.

If you have written software worth selling, the awkward part is rarely the software. It is everything around it: issuing keys, binding a copy to one customer, knowing what is installed where, handling renewals, and revoking access without breaking someone mid-project.

Very few people offer this work, which is why it usually ends up half-built by whoever had time. It is also the kind of thing that is expensive to retrofit once copies are already out in the world.

This is the one service where the evidence is easiest to check: the platform you are reading this on ships with exactly that engine, licensed the same way, to its own customers.