Custom software
Web apps, client portals, internal tools, and AI-powered applications. We spent years implementing the big platforms. Now we build what they could never quite be, a system shaped to how your people actually work.
100% code ownership/unlimited users/no license lock-in/every account in your name
$ badger scope --from discovery.md
41 workflows mapped ok 3 spreadsheets retired
$ badger build --phase 1
schema ok auth ok rls policies ok
job board ok quoting ok qbo sync ok
$ badger test && badger review --security
212 passing ok 0 secrets in code ok
$ badger handover --accounts client
repo, db, hosting: yours
Sound familiar?
You shouldn't have to redesign your business to fit your software. Yet here most companies are. The people who call us are usually living with several of these at once.
Real money every year for platforms your team uses a tenth of, priced per seat, forever, with a renewal conversation you always lose.
Ten disconnected tools held together by Zapier and habit, and a person who spends their week retyping between them.
The real business runs in workbooks because the systems you pay for can't keep up with how the work actually moves.
Reports that are stale, partial, or quietly reconciled by hand before every meeting, so nobody fully trusts a number.
Paying specialists by the hour, year after year, to configure around the limits of software you don't own.
Generic platforms designed for nobody in particular, forcing your process to bend to theirs one workaround at a time.
Why custom, now
A platform built for every business at once has to stay general, and your business isn't general. So your team adds a workaround, then a second tool, then a spreadsheet to reconcile the two, and the monthly bill grows with every seat you add.
Living with that used to be the sensible choice, because custom software was slow to build and risky to keep. Neither is true anymore. AI-assisted engineering changed the economics of building, and modern code written to be read changed the economics of keeping. A system built around your process is now practical at a cost that competes with what you already pay in subscriptions, and any capable developer can pick it up after us.
You get one cohesive system with unlimited users, and you own it outright.
What we build
The category most teams force into a spreadsheet or a board tool.
Built once, around how you actually sell.
Your customers, under your brand, in one place.
The connective tissue, with error handling that takes money seriously.
The stack
Boring on purpose. Your system runs on the same modern, battle-tested infrastructure serious product teams ship with, and every piece of it sits in accounts you own.
Front end
React and TypeScript, responsive by default so it works on a phone in the field.
Data
Postgres with row-level security, so one customer can never read another. Realtime where the workflow needs it.
Back end
Edge functions for the logic, a secrets vault for credentials, and audit trails where the data deserves them.
Wired in
Stripe for payments, Twilio for SMS and voice, transactional email, and whichever frontier AI models win on your task.
Where AI belongs inside the system, it earns its keep on operational work. Reading and drafting documents, classifying what arrives, generating the weekly numbers, and watching for the anomaly a person would catch three weeks late. The AI-powered apps page says where it helps and where it's a demo.
The honest comparison
Three ways businesses get software, compared on the things that still matter in year three.
| Compared on | SaaS platform | Traditional dev shop | Black Badger |
|---|---|---|---|
| Built for your workflow | Generic by design | Eventually | From the first screen |
| You own the code | Never | Sometimes, read the contract | Always, in your repository |
| Per-seat fees | Forever, and they grow | None | None, unlimited users |
| When it breaks | A ticket queue | Depends who's left | A person who knows your system |
| Leaving is possible | Export and hope | If the code is readable | The code is written for it |
The order of work
Six stages, always in this order. Nothing below is a date. The sequence is what we commit to publicly, and the runway is set in your written scope once we've seen the real shape of your work.
You describe how work moves through the business and where it stalls. We ask the awkward questions. Who retypes that? What happens when the person who knows is away? Which report does the owner actually read? You leave with a plain read on whether a build makes sense, and a written summary either way.
For anything sizeable this is paid, and it's where the scope stops being a guess. We watch the work happen, read the spreadsheet that's doing the real job, and map every screen and field of the system you're leaving. AI tooling reads an incumbent system more completely than a person working through it by hand, which is the single biggest change in how this is done now.
Deliverables you can point to, the phases they fall into, and the assumptions on both sides, in writing, before anything is signed. It names what is out of scope as explicitly as what is in. If a scope dispute happens later, it's because this document was vague, so we'd rather it be long.
You see working screens with your own workflow on them early. Feedback goes in through a tool inside the app itself, so a comment lands on the screen it's about. Nobody has to go digging through a document for it. Small sensible additions get done without a change order.
Your records come across, get checked against the old system, and get checked again by the people who know what the numbers should say. For anything critical the two systems run side by side. They stay that way until the new one has been right for long enough that nobody's nervous, and only then does the old subscription get canceled.
Documentation, training for the people who will use it, a security review, and every account already in your name. After that you can keep us on an optional support plan, bring in any developer you like, or run it yourself. There's no license and no renewal conversation waiting for you.
The stakes
More than the money. A custom build that fails doesn't fail quietly. It fails after your team has already changed how they work, and the fallback is a spreadsheet somebody's been maintaining in secret. It happens four ways.
The new system launches, and the workbook that was doing the real job stays open next to it because the build missed something that mattered. Now you've got two sources of truth and a license you no longer need. This is what discovery is for.
Records land with dates in the wrong format, statuses that don't map, or a customer field silently truncated. Nothing errors. The reports are simply wrong, and nobody trusts the new system again without a reconciliation they can read themselves.
Clever code nobody else can read leaves you dependent on whoever wrote it. That was the historical case against custom software, and it was a fair one. It's only untrue when the code is written to be picked up, and when the accounts are in your name.
The software works. The team keeps doing it the old way, because nobody who does the work was in the room while it was designed. Adoption gets decided during discovery and training, long before any launch announcement.
For what the wider industry actually spends on getting business systems in place, and where the money goes, the implementation cost research on this site collects published figures by company size with the sources attached. It's the most checkable thing we publish, and none of it is our own pricing.
Limits
Cheaper to say now than to discover in month two. If one of these is what you actually want, we're the wrong firm, and you'll hear it on the first call rather than after a deposit.
If the process was never written down and your team doesn't agree on what it should be, discovery comes first. Writing code against a disputed process is the most reliable way to spend a budget and change nothing.
Clinical software, payroll, tax engines, and accounting ledgers exist for good reasons and carry compliance weight. We integrate with those. Replacing one just because it would make a bigger project is upselling dressed up as advice.
The code repository, the database, the hosting, and the email sending are all created in your name from day one. We're invited in as administrators and you can remove us. Nobody should be able to hold a business hostage over a login.
If a feature can't name the operational number it moves, it's a demo. AI earns its place reading documents, drafting, classifying, and checking, the parts of your system where it removes real work. A chatbot that impresses in a meeting and gets switched off by March is none of those.
Coming from a platform
We implemented and supported most of these for years and have integrated with several of the rest. That's why we can tell you where each one fits and where it fails, and each page below says so plainly.
Questions
Answered in full, including the two questions this industry usually deflects.
When your team is already changing how it works to fit the tool, when the per-seat bill keeps climbing as you grow, or when you're running two or three platforms plus spreadsheets to cover what one system should do. If a platform genuinely fits you and you're not fighting it, keep it. We'll say so on the call.
Web applications your team uses every day. CRM and quoting systems, project and job management, client portals where your customers see status and documents, internal tools that replace spreadsheet chains, dashboards that pull from all of it, and the integrations between your systems (QuickBooks, Stripe, Shopify, and whatever else you're running). Mobile-responsive by default, so it works on a phone in the field.
You do, completely. The source code lives in a repository in your name. The database, hosting, and email sending run on accounts created in your name. We're added as administrators to build and support it, and you can remove us. There's no license, no seat count, and no vendor holding anything back.
Small, sensible additions during the build usually just get done. After launch you can keep us on an optional support plan, bring in any developer you like (the codebase is written to be picked up by someone new), or ask us for a scoped follow-on. You're never locked in to us for changes.
Row-level access rules in the database from day one, no credentials in code, secrets in a vault, and a security review before handover. When we take over an app someone else built, the first thing we look for is exactly that kind of shortcut. It's the most common problem we find.
A strategy call comes first. Then a written scope with the deliverables and assumptions spelled out, then a build where you see working screens early and give feedback inside the app, then handover with documentation and training. Larger engagements start with a paid discovery or our AI-run project assessment, so the scope is grounded before anyone commits.
No, and no honest firm can. A build is scoped around what it has to do, how many people use it, and what it must connect to, so a starting-at figure would be a guess dressed as a fact. The implementation cost guide on this site collects published figures from analysts and vendors on what business system implementations run by company size, with sources you can check. Your own number starts at the strategy call and firms up in a written scope.
It comes with you, and we prove that before you give notice. Early in every engagement we run an export check against the platform you're on, because export limits are where people get caught out. Records usually come out cleanly. Automations, dashboards, permission schemes, and form logic mostly don't come out at all, and those get rebuilt on the new side. You see that list in writing while you still have options, before the notice window closes.
Yes, and for anything sizeable that's what we recommend. A phase is a piece that stands on its own and is genuinely useful the day it lands. A half-finished slice waiting on the next phase doesn't count. So you get value before the whole thing is done, and a phase boundary is a real place to stop if priorities change. The written scope names the phases and what each one contains.
A process nobody has agreed on. If your team can't describe the workflow you want, only the one you have, then software just makes the disagreement faster. It won't fix data that was never trustworthy either. Garbage carried across is still garbage, with a nicer interface. And it doesn't replace a specialist system where one genuinely exists, such as clinical software, payroll, or a tax engine. We integrate with those.
Yes, with the same conditions any software needs, and AI doesn't change what those are. The system still needs row-level access rules so one customer can't read another one, secrets in a vault and never in the code, tests that run before anything deploys, and a security review before handover. We use AI tooling to write and check code faster. We don't use it to skip the review. When we take over an application somebody else built, the most common finding is credentials hard-coded into the app. That's a human shortcut, not a machine one.
From the knowledge base
Reference pages, not sales pages. Each one is useful even if you decide to stay exactly where you are.
Seven tests you can run against your own operation this week. Most businesses that run them find a configuration problem, not a build.
A sourced comparison table at 50, 100, 250, 500, and 1,000 employees. Every figure is cited and dated, and the thin-data cells say so.
From the blog
Custom software /
Getting ten years of records, attachments, and history out of a SaaS platform is doable, but it's the part most teams underestimate. Here's how the work really goes and what breaks.
Custom software /
Custom software isn't always the answer. Here's the arithmetic, the warning signs, and the honest caveats that tell you whether to renew your platform or replace it.
Custom software /
Cancel a SaaS subscription and your data doesn't vanish, it gets locked behind a login. Here's what an export really gives you, what never comes out, and when owning the system is cheaper.
Book a strategy call, or send a short note about what's happening today.
