In this guide 6 sections
Buy when your contracts are plain. Fixed fees and flat subscriptions fit any package, but bundled plans, usage meters and customer-specific rate cards push staff into spreadsheets, so build only the contract logic. Many firms do both. Insist on a full data export first.
Start with the contracts, not the feature lists
Pull ten signed agreements from the last year and list every pricing method, from seat fees and day rates to milestone payments, retainers and overage tiers. Vendor demos show clean examples. Your contracts are not clean.
A package that handles eight of ten pricing shapes still pushes the other two into manual work, and those two often belong to your largest customers, who negotiated hardest.
Count the odd ones. Two odd contracts in ten say buy. Six in ten say build, because every odd contract becomes a monthly correction on a spreadsheet tab that only one person understands.
- Rate cards that differ by customer and by role
- Minimum commitments with rollover hours
- Usage tiers read from product logs
- Co-termed renewals across several products
- Credits issued after an incident
What off the shelf tools do well
Mature PSA suites handle timesheets, resource booking, project budgets and a basic invoice run without fuss, which covers what most delivery teams do every single week. Billing platforms manage card retries, tax lines and dunning emails far better than a small team could write them between client deadlines.
Buy these parts. Nobody wins customers through retry loops.
Check the export before you sign anything. If you can pull every contract, timesheet and invoice line out as CSV or through an API, a later move away from that vendor costs far less.
Where the packages start to bend
The strain shows at the joins. Sales closes a deal in the CRM. Finance keys the plan into the billing tool, and delivery tracks hours in the PSA, so three systems hold three versions of one agreement.
A change request approved in a Slack thread never reaches the rate table, so the invoice follows the old rate and the customer disputes it at the quarterly review. Everyone remembers agreeing something different.
Watch the first week of each month. If your people spend that week reconciling the CRM, billing tool and PSA, the packages are bending, and that reconciliation is the work a custom layer should take over.
What a custom back office would hold
Keep the build small. Hold one contract record that owns the plan, rate card, term, renewal date and every change, and let time entries, usage readings and invoice lines point back to it.
The payment gateway, ledger and CRM stay as they are, while the custom layer sits between them and pushes clean data in both directions. Webhooks from the payment gateway and nightly exports from the data warehouse feed it, so staff never retype a figure that a system already knows.
A first release can be a contract register, a usage import and an invoice preview, which finance checks before anything posts to the ledger. Good tooling does not fix a missing process, and a custom build that copies a broken approval flow only makes the same mistakes faster and harder to see.
- Contract register with versioned amendments
- Rate lookup by customer, role and date
- Usage import from product logs or a data warehouse
- Invoice preview with a variance flag against last month
- Sync to the ledger and the CRM
A test to run before you decide
Time one full billing cycle. Record how many hours go to reconciling, correcting and reissuing invoices, who does that work, and the cause behind every disputed line.
Then price both paths over three years. Licence fees plus manual hours sit on one side, build cost plus hosting and upkeep on the other, plus the cost of living by one vendor’s release plan.
Take that sheet to the planning meeting. If the manual hours dwarf the licence fees, scope a contract register first, and track every correction too, including credit notes, reissued PDFs and apology emails. Leave everything else bought. The Friday hours spent explaining to a customer’s accounts payable clerk why a line moved belong on the sheet as well.
Build or buy scoring sheet
A single printable sheet in three parts. Part one runs your last ten contracts down the side and pricing shapes across the top, with a tick where a candidate tool cannot model it. Part two logs reconciling hours by role. Part three compares three year cost for buying, building and a mix, with a line for the renewal and amendment handling each option would need.
Open a blank worksheet to printQuestions owners ask
Can a small software firm afford a custom back office?
Often, if the scope stays narrow. A register and preview cost far less. Keep the ledger and payment gateway bought, and build only the layer that holds your own pricing rules, such as bundled plans and customer rate cards.
Is a PSA the same as an ERP?
No. A PSA focuses on projects, time, resources and billing for service work, while an ERP covers finance, purchasing and inventory across the whole company. Many software firms run a PSA beside a light accounting tool such as Xero or QuickBooks, and move to a heavier ERP only when purchasing and stock matter.
What if we outgrow the package we buy?
Plan for it on day one. Insist on full export of contracts, time entries and invoices, and keep your own contract register, so that a later switch means moving data instead of rebuilding history.
Who should own the decision?
The operations head decides. Seat the finance lead and a delivery manager beside them, because those three see the billing errors and the workarounds first and will live with whichever choice you make.