Out with SaaS.In with custom.
Some problems are ordinary enough that a starter does the job in a couple weeks. This page is about the rest — built from scratch, in your repositories, billed by the hour against an estimate you agree first.
Open source projects
Public on github.com/JIGGAI
AI plugins
Published on npm, free to install
AI plugin installs
65,377 to date, per npm
AI monthly plugin installs
2,811 in August 2026, per npm
Four signals you have outgrown the homegrown.
Not every job needs its own software. These are the cases where bending something that nearly fits has quietly become more expensive than building the thing you actually described.
The work crosses six systems and two of them are older than the company.
Integration surface is the usual reason a starter stops fitting. The logic is ordinary; the plumbing is not.
Every competitor does this differently, and the difference is the business.
If the process is your advantage, standardising it away is the one thing you should not do.
A regulator has to be able to follow the decision two years later.
Constraints on evidence and retention usually shape the build from the first line rather than being bolted on.
We know what we want and no one sells it.
The most straightforward case, and the one where a custom build is genuinely cheaper than bending something that nearly fits.
AI is making custom great again.
Most off-the-shelf products cover some areas but not all, and your workflow ends up a hodgepodge of systems and spreadsheets. AI is giving businesses the power back — build exactly what you need, at or near the annual cost of a SaaS product.
Increments, and a real stop after each one.
Nothing about a custom build should require you to commit to the whole of it before seeing any of it.
Scope from the assessment
We build from the guide the assessment already produced — the ranked opportunity, the systems inventory, and the measure that decides whether it worked. If you have not had an assessment, this phase is where one happens.
- Written scope, drawn from the guide
- An hours estimate, with the assumptions listed
- Agreed before any build hours are billed
First increment
Something running, in your own repositories, doing the narrowest useful version of the job. Not a demo — a thing the people who would use it can actually use, so their objections arrive while changing course is still cheap.
- Runs in your infrastructure, not ours
- Reviewable as a pull request like anything else
- Stop here and you keep what is built
Widen or stop
We widen the scope only where the first increment earned it. Plenty of engagements end at this point because the narrow version turned out to be enough, which is a good outcome and we will say so.
- Re-estimated at each widening
- You are told when an estimate moves, not after
- Scope never widens without your agreement
Maintain
From here you have your own team of AI experts on hand. Software does not hold still — the tools it talks to change their APIs, models get better and cheaper every few months, and your operation moves underneath all of it. We stay on as the people who notice and act on that, and as the people you ask about anything AI across the business, including the parts we had nothing to do with.
- Your own AI team, without hiring one
- Kept current as tools, APIs and models change
- On hand for anything AI, including what we did not build
Everything, including the reasoning.
A custom build is only worth more than a starter if you own it afterwards. Otherwise you have rented something bespoke, which is the worst of both.
The code, in your repositories
Not a hosted service you rent from us. If we disappeared tomorrow, the thing keeps running and someone else can maintain it.
A runbook, not tribal knowledge
How it runs, what it costs, what breaks it, and what to check first. Written for whoever picks it up — including us, a year from now.
The reasoning, kept
Why each decision went the way it did — including the alternatives rejected, so a future team can revisit them knowingly.
A measure that already exists
The success measure was agreed before the build, so nobody has to invent one afterwards to justify what happened.
You keep a team of AI experts on hand.
Every starter and every custom build comes with people attached. Hiring that expertise in-house means a search, a salary and a bet on one person; this is the same thing on hand, at whatever size you need it — and the size is yours to change whenever.
The floor
Keeping it alive. Dependencies and security patches, the plugins kept current, and someone who answers when it breaks. Not a support package with a response-time table — the minimum that stops working software quietly rotting.
Your AI department
Everything above the floor. We take work like anyone else on your team — your standups, your backlog, your priorities — and the thing we built is simply one of the things we look after. New automations, the tools you bought and never rolled out, the model that got cheaper last month, the idea someone raised in a meeting: it all has somewhere to go.
The two are ends of a range rather than a choice between packages, and moving along it as the year goes is expected. The level is yours to set.
And you can leave with it.
The software is yours — it always was, in your repositories under your accounts. If you want to take it somewhere else, we will always facilitate a clean transfer of both the technology and the institutional knowledge behind it: the runbook, the reasoning, and a conversation with whoever picks it up. An ongoing relationship you cannot leave is not a relationship.
Starter or custom?
The honest comparison. A starter is still the cheaper answer when somebody has already solved your problem — this is how to tell which side you are on.
| Question | Starter | Custom build |
|---|---|---|
| Has someone solved this before? | Yes — the base exists | No, or not in your shape |
| Time to something running | Two to four weeks | Two to three weeks per increment |
| How it is billed | Fixed, agreed before we begin | Hourly, against an estimate |
| Is the process your advantage? | No — it is plumbing | Yes, and worth keeping |
| Systems it has to touch | One or two | Several, some of them old |
| What you own at the end | The code, in your repos | The code, in your repos |
The last row is deliberately identical. Ownership is not the thing you buy by going custom — it comes with both.
What people ask about custom work.
Why hourly rather than a fixed quote?
Because the scope is yours to change once you have seen the first increment, and that is the point of building in increments. A fixed quote would only mean padding the estimate to cover a change we actively want you to make. We estimate the range up front and tell you when the estimate moves rather than after.
Do we need an assessment first?
Not formally, but the scope has to come from somewhere. If you already know precisely what you want built and can hand us the systems it touches, we can start from that. Otherwise the assessment is the cheapest way to produce a scope worth billing against.
What if we want to stop halfway?
Then you stop, and you keep everything built up to that point — running, in your repositories, with the runbook. Increments exist so that stopping is a real option rather than a threat.
Could a starter do this instead?
Often, and we would rather tell you that on the free call than four weeks into a custom build. Some of what arrives on this page turns out to be a starter with one part changed, and we will say so when it is.
Who actually does the work?
We build all our own. There is no separate delivery team and no handoff from the people who scoped it to the people who build it — the engagement is small enough that the same hands do both.
Tell us what you are trying to build.
Half an hour, no charge. If a starter would do it faster and cheaper, that is what we will tell you.