Custom systems · Grid Forge℠
The spreadsheet got you this far.From here on it’s a system.
Custom systems are built for your process, not the other way around. From scratch, or taking over what already exists: a prototype, a stalled no-code or AI-generated code that stopped moving.
The problem
Do any of these sound familiar?
If one of them describes your week, the rest of this page is about that.
The spreadsheet became a database
It has formulas nobody understands, freezes when the file is full and two people cannot edit at the same time.
The off-the-shelf system forces the operation to contort
You pay a license to work the way the software dictates, and still keep a spreadsheet on the side for what it can’t do.
The AI-built prototype breaks with real users
The demo worked. Then ten people came in at once, real data showed up, and what was fast became a queue.
There’s code, but no one knows what it does
Whoever built it left, or it was a tool that generated it on its own. Touching it became a gamble.
Every change depends on one person
The product moves at the speed of someone’s calendar. That’s a risk, not a saving.
The work
From scratch, or from where it stopped.
Building from scratch is the simple case: we design the data model, the interface and the rules together with whoever will use it, and ship in parts that already work.
Taking over a started project is the most common case today, and the one almost no one does. Starting got cheap: anyone can stand up a prototype in an afternoon with Lovable, Claude Code, Cursor or v0. Keeping it running stays expensive, and that’s where the project stalls.
In that case the work opens with an audit: what stands, what can be reused, what can’t handle real users. You get that map before you get the bill.
What you get
- A written audit of what already exists, when it exists
- Data model and rules agreed before the code
- Delivered in parts, each one already in production
- Code in your repository, your access from the start
- Environment, deploy and monitoring set up along with it
How it happens
Four steps, in this order.
- 01
Diagnosis of what already exists
We look at the process, the code and what is stuck today before proposing anything.
- 02
Scope, timeline and price
You approve a closed path. No open-ended scope running loose.
- 03
First version in production
A useful slice live early, with real users, instead of six months in the dark.
- 04
Grow and maintain
The system stays up with the people who built it nearby. That’s the part that’s usually missing.
In practice
What we usually build
No closed list. If your case isn’t here, it probably looks like one of these.
What we work with
Continuity
Product
Foundation
Before you decide
What people usually ask.
Yes, and it’s a big part of what we do. The first step is always the audit: read what exists, run it, and write down what stands and what doesn’t.
You get that diagnosis before deciding to continue. If the conclusion is that rebuilding is cheaper than fixing, we say so, with the reason.
Almost always, and the problem is rarely ugly code. What’s usually missing is what the demo doesn’t show: a data model that can grow, access control, error handling, an environment separate from production.
We keep what the AI got right, usually the interface and the happy path, and rebuild the foundation. You’re the one who found the product, and that’s not thrown away.
Yes. The repository is yours, the access is yours, and the infrastructure accounts are in your name from day one.
If one day you want to move the project to another team, there’s no knot to untie.
Yes, and it’s usually the right path when it’s still an idea. A lean first version in production, with real users, answers in weeks questions a meeting can’t answer in months.
Only after that does it make sense to decide what to grow.
The price comes after the diagnosis, along with scope and timeline, and it comes fixed. We don’t work with open hourly billing running without a cap.
Within 24h of first contact you already get a direction, even before the proposal.
The other work areas