03 Services
Custom web applications that replace the spreadsheet.
Internal ops tools, client portals, and customer-facing web applications. Taken one dedicated build at a time so the owner stays on the work. Fixed scope. Undivided attention.
Problem
The company is running on a sheet nobody owns.
A spreadsheet is fine until it is the operations system. Then versions fork, permissions rot, and the person who built the formulas is the only one who can change a status. Off-the-shelf SaaS almost fits, so the team keeps a shadow process beside it.
A custom application is not a badge of sophistication. It is what you build when the bottleneck is the tool itself: intake that must match your workflow, a portal your clients will actually use, or an internal app that encodes the rules you already follow on paper.
I take one of those builds at a time. Larger work is welcome when the scope is honest. A graveyard of half-shipped portals is not a studio.
- Status, inventory, or jobs living in a shared spreadsheet
- Clients emailing for updates the portal should already show
- SaaS tools that almost fit, so staff keep a side process
- No owner for the workflow once the original builder leaves
Who
Who this is for.
Operators whose bottleneck is the tool itself — not a missing landing page.
-
01
The sheet is the company
Status, inventory, or jobs live in a tab named FINAL_v7. Versions fork. One person owns the formulas.
-
02
Clients email for updates
The portal should already show the status. Instead, delivery lives in threads.
-
03
SaaS almost fits
You bought the tool. Staff still keep a shadow process beside it because your rules will not bend.
-
04
One dedicated build
You need an application, not a platform rewrite. If the job is a marketing site, that is website design.
Examples
What this looks like in practice.
The smallest application that removes the bottleneck. Not a graveyard of half-shipped portals.
-
Client status portal
Jobs, files, and next steps in one login. Clients stop asking “any update?” because the record is already there.
-
Internal intake and assignment
A shared sheet becomes an app with permissions, statuses, and an owner. The original builder can leave.
-
Customer app with payments
Login, records, and Stripe on a workflow that shelf software will not encode. You own the code.
-
Ops dashboard on the CRM
Sales and delivery share a record in HubSpot or the tool you already run. No second source of truth.
Process
How the work runs.
We do not start in a redesign of the whole company. We ship the smallest application that removes the bottleneck.
-
01
Name the job
Who uses it daily, what a record is, and which rule cannot be broken. If that is fuzzy, we audit before we build.
-
02
Build the core path
The screens and data model for the actual job. Proven tools. No framework for its own sake.
-
03
Wire payments, CRM, and docs
Stripe, HubSpot, QuickBooks, auth, the files you already keep. Test the ugly cases: duplicates, permissions, empty states.
-
04
Launch and stay on it
Go live with the people who will use it. Watch the first weeks. Optional retainer. No lock-in to a platform you cannot leave.
Integrations
Wired to what you already run.
We plug in. The workflow does not wait on a new stack.
- Stripe
- HubSpot
- QuickBooks
- Google Sheets
- Auth / SSO
- Shopify
- File stores
- Existing APIs
Outcomes
What changes when it ships.
-
01
One source of truth
Status is not hiding in a thread or a tab named FINAL_v7.
-
02
The workflow matches how you work
The app encodes your rules instead of forcing a generic pipeline.
-
03
Clients and staff stop chasing updates
A portal or internal view answers the question before it is asked.
-
04
Undivided attention on the build
One custom app at a time. You are not in a queue behind five other products.
Enquire
Tell us where the friction is.
Write where the work is stuck. I read it and reply. No build commitment.