Every service firm eventually needs software that fits how it actually works: a client portal shaped around its intake process, a CRM that tracks the stages its deals really move through, an invoicing flow that matches how it bills. There are three ways to get that software. Buy it off the shelf, build it custom, or fork a ready-made application and adapt it.
For most of the last two decades there were only two realistic options, buy or build, and each forced a hard trade-off. Forking is the third path, and it became practical only recently. This guide explains what each option is, what it costs, and when to choose it.
Quick comparison
| Approach | What it is | Speed to live | Fit to your firm | Needs engineers | You own it |
|---|---|---|---|---|---|
| Buy | Subscribe to an off-the-shelf tool | Hours | Low | No | No |
| Build | Commission custom software | Weeks to months | High | Yes | Yes |
| Fork | Adapt a ready-made app to your firm | Hours | High | No | Yes |
Buy: fast, maintained, but never quite fits
Buying means subscribing to an off-the-shelf product: a CRM, a help desk, an invoicing tool, an intake form builder. It is the default choice, and for good reasons. You are live in an afternoon, the vendor handles maintenance and security, and the cost is predictable.
The problem is fit. Off-the-shelf software is designed for the average of thousands of firms, which means it fits none of them precisely. You adapt your process to the tool rather than the reverse, and you do it repeatedly, because no single product covers intake, CRM, invoicing, follow-up, and support. The result is a familiar pattern:
- Five subscriptions that do not talk to each other. A lead captured in your intake tool does not automatically become a contact in your CRM or an invoice in your billing tool.
- A per-seat bill that grows with headcount. Every new hire multiplies across every tool.
- A person whose real job is reconciliation. Someone spends hours each week copying data between systems so the left hand knows what the right is doing.
- No single client record. The same client exists as four partial copies, and none of them is complete.
Individually, each tool works. Collectively, they fail, because the thing the firm actually needed - one connected system - was never on offer.
Choose buy when the need is generic and a category leader already solves it well, for example email, accounting, or document signing. Avoid buy when the work is specific to how your firm operates, which for most service firms is most of the work.
Build: perfect fit, but you need a software team
Building means custom software written for your firm exactly as it works. This is the theoretical ideal: no compromises, no adapting your process, no vendor sprawl, and you own the result.
The problem is staffing. Custom software requires engineers, and a $3 million law firm or a fifteen-person consultancy does not have a software team and should not have to build one. The costs are larger than they first appear:
- You are running a development project, with the specification, timelines, and coordination that implies.
- You pay by the hour, and estimates for custom software are notoriously optimistic.
- You own maintenance forever. The build is not the end of the cost, it is the beginning. Someone has to fix, update, and secure it indefinitely.
Building solves the fit problem and replaces it with a staffing problem most firms cannot afford.
Choose build when you have engineering capacity and the software is core to your competitive advantage, so owning it outright is worth the cost. Avoid build when your product is legal work, consulting, or brokerage rather than software, because the software rarely clears the bar that justifies a dedicated team.
Fork: the fastest way to build without engineers
Forking means starting from a production-ready application that already exists - a CRM, an intake flow, a client portal - taking it as your own, and adapting it to fit. It combines the speed of buying with much of the fit of building, and you own the result rather than renting it.
Two developments made forking practical in 2026:
- Ready-to-run applications wired to a real backend out of the box. Forking one is not a coding project. It is a starting point that already works, with auth, database, and logic already connected, so the firm's data flows through it from day one.
- AI that does the adapting. Point your AI tools at the forked application and describe the change you want, and the AI modifies the software directly, in a single session rather than a development sprint. The firm supplies the judgment about how the work should flow. The AI handles the implementation.
The outcome is software shaped around your firm, live in hours, with no engineers on staff and no five-vendor stack to reconcile. Because everything you fork runs on one shared backend, a client record created at intake is the same record the CRM, invoicing, and support all read from, rather than four disconnected copies. Fixing the fragmentation is not an extra integration step, it is the default state.
Choose fork when you want custom-fit software without hiring a team to build it. Forking is not a lesser version of building; it is how most service firms now build, just starting from working code instead of a blank page.
How to decide
The decision comes down to two questions:
- How specific is the need to your firm? Generic needs are well served by off-the-shelf tools. Specific needs are not.
- Do you have engineers? Traditional building requires them. Buying, forking, and building with Butterbase do not.
Applied together:
- Generic need, any firm → Buy. There is no reason to reinvent a solved problem.
- Specific need, with engineering capacity and strategic importance → Build. Owning it fully is worth the cost.
- Specific need, no software team → Fork or build with Butterbase. Start from a ready-made application, or describe what you need in plain language and let AI build it on one shared backend. Either way, the firm gets software that fits without hiring engineers.
Most service firms fall into the third case far more often than they realize. The work is specific, the firm has no engineers, and until recently the only choices were a tool that did not fit or a build they could not staff. Forking - and building on a platform that already has the backend, auth, and rules in place - removes that trade-off.
Butterbase is built for firms that need custom software without a software team. Fork production-ready applications, or connect your AI tools via MCP and build exactly what you need in a single session - either way, everything resolves to one shared record on one backend you own. If your firm has been choosing between software that does not quite fit and a build you cannot staff, there is now a better answer. Related reading: What Your Firm Actually Spends to Run on Five Tools and How Service Firms Grow Revenue Without Growing Headcount.
Frequently asked questions
Forking means taking a production-ready application - a CRM, client portal, intake flow, or support desk - and adapting it to match how your firm works. Unlike buying, you own the result. Unlike traditional building, you start from working software instead of a blank page and you do not need engineers on staff. In 2026, AI coding tools can handle most of the adaptation, so the firm supplies the judgment about workflow while the agent handles the implementation.
No. Building from scratch starts with requirements, designs, and a development project measured in weeks or months. Forking starts from an existing application that already has auth, a database, and working logic. The work is adaptation, not invention, which is why a forked application can be live in hours rather than months. Both produce software you own; forking just removes the engineering bottleneck.
Buy when the need is generic and a category leader already solves it well. Email, accounting, and document signing are good examples: the problem is similar across firms, and the best product is good enough. Buy becomes expensive when the work is specific to your firm's process, because then you are paying for features you do not use and adapting your workflow to someone else's average.
Traditional build makes sense when the software is core to your competitive advantage and you have the engineering capacity to own it long term. A technology company whose product is the software itself should often build. A law firm, consultancy, or agency whose product is expertise usually should not, because the staffing and maintenance cost outweigh the fit. That is why agent-native platforms like Butterbase let service firms build custom software without maintaining a dedicated engineering team.
Two things changed. First, ready-made applications now ship wired to a real backend - auth, database, storage, and logic already connected - so forking gives you a working system immediately. Second, AI coding tools can adapt that system, or even build new features from description, through natural language in a single session. The engineering bottleneck that used to force firms to buy or hire is gone.
Yes. Butterbase exposes every backend capability - database, auth, storage, functions, realtime, and AI gateway - as MCP tools. Your AI agent can create tables, write policies, build API endpoints, and wire up a frontend in a single session. You describe what the firm needs; the agent builds it on Butterbase's managed substrate. No engineers required.