Construction · CRM
A multi-agency CRM for roofing companies
Roofing services platform (US)
CodeIgniterReactPHPMySQLStripeTwilioQuickBooks
Custom software
Custom software shaped around the way your team actually works.
Software for one organization and the people inside it. We start from the workflow your ops team already runs: spreadsheets, workarounds and the steps nobody documented.
The brief, honestly
Your workflow first. The software second.
Most of these briefs start in the same place. A department has outgrown its spreadsheets, or a bought platform covers most of the job and the rest runs on a shared inbox and someone's memory. Nobody wants software. They want the gap closed.
So the first thing we build is a map of the department workflow as it actually happens, role by role, including the steps people invented to get around the system they already have. That map decides the data model, the permissions and the screens. Get it wrong and no amount of clean code saves the project.
A back-office system gets sold once, to you. That changes what matters. Nobody is being persuaded to adopt it — they are paid to use it. So we optimise for the two things you will care about long after launch: staff can be trained on it, and the next developer can read it.
Problem 01
We're running the whole department out of spreadsheets.
We map what those sheets actually do, then replace them one workflow at a time. The formulas people quietly rely on become features, not casualties.
Problem 02
The off-the-shelf CRM fits most of what we do, not the part that matters.
That last part is usually the whole reason you're calling. We build the CRM around your pipeline instead of bending your pipeline around somebody's default fields.
Problem 03
Every team keeps its own version of the truth.
One data model, one set of records, role-based access so each department sees its own slice. Reconciliation stops being a monthly job.
Problem 04
The last build was handed over with no documentation.
A runbook, a data dictionary and a walkthrough recorded for whoever inherits it. We write the handover as we build, because written afterwards it is always thinner.
What's included
Scope, spelled out.
Workflow archaeology
We sit with the people doing the job and record the real sequence, including the steps that exist only because the current system is bad.
CRM built to your pipeline
Stages, fields and permissions that match how your team sells, with the reporting your sales lead asks for on Monday morning.
ERP and back-office modules
Inventory, purchasing, invoicing and approvals as separate modules on one data model, so a change in one place does not break the next.
Dashboards people trust
Numbers computed one way, in one place, with the definition written next to them. Nobody exports to a spreadsheet to check your maths.
Roles and audit trail
Role-based access per department, plus a record of who changed what and when. Useful for compliance — indispensable during an argument.
Data migration and cutover
Your existing records moved, deduplicated and reconciled, with a rehearsed cutover and a way back if the first evening goes badly.
Integrations to what you run
Payments, accounting, calendars, messaging and measurement tools wired in, so staff stop retyping the same value into a second system.
How we work
What actually happens, week by week.
01
Shadow the work
We sit with each role and write down the real sequence, including the workarounds.
02
Model the domain
Entities, states and permissions on paper first, reviewed with the people who own each step.
03
Module by module
One workflow shipped at a time, demoed to its actual users before the next one starts.
04
Migrate
Records moved, deduplicated and reconciled, then a rehearsed cutover with a documented way back.
05
Hand the keys over
Runbook, data dictionary, admin training and a recorded walkthrough for whoever maintains it.
Tech stack
The tools we actually use here.
We don't pick the stack before we understand the workflow. PHP and JavaScript on the server, React or Angular in front, and a relational database unless the data says otherwise.
PHPNode.jsTypeScriptReactAngularMySQLPostgreSQLMongoDBDataTablesStripeQuickBooksTwilioGoogle CalendarAWS
What you get
Deliverables, outcomes and who this is for.
Deliverables
- Workflow map, role by role
- Domain and permissions model
- Working modules, demoed as they ship
- Migrated and reconciled data
- Runbook and data dictionary
- Admin training and walkthrough
Outcomes
- Staff stop maintaining spreadsheets
- One set of records, one definition
- A system your next developer can read
- Cutover with a documented way back
Ideal client
Operations, finance and product leads inside one organization who need software their own staff will use every day.
Proof
What these builds replaced.
Education · SaaS
Multi-city sports academy fee collection
Sports academy (multi-city)
SlimReactMySQLTailwind
The chain, not the screens
The roofing build's real subject was one chain: estimate, work order, invoice, payment receipt. Modelling it as a single sequence with states, rather than four screens that happen to link, is what let scheduling and pricing hang off it later. The weather-aware calendar was only possible because the sequence had a shape.
Configuration beat custom code
The academy fee system had to handle cities, centers and batches the client kept adding, plus monthly, quarterly, half-yearly and yearly plans. We made those rows in a table instead of branches in code, including receipt numbering keyed to location. Adding a center became an admin task — not a release.
Frequently asked
Questions we get on the first call.
Both, on different parts. Discovery and the first module we quote fixed, because we can see them. The rest we price per module once the workflow map exists, which is usually where scope doubles. A single fixed number for a whole back-office system is either padded or a fight later. We'd rather say that up front.
You do, all of it. Source, infrastructure config, migrations and documentation, in your accounts and your repositories from the first commit rather than transferred at the end. We keep no license, no runtime dependency on us and nothing you need our permission to change. If we reuse a generic helper across clients, we tell you which and why.
Less than you fear and more than you budgeted. Expect a few hours per role across a couple of weeks: one session watching the work, one reviewing the map we wrote, one arguing about edge cases. The people who do the job daily are the only ones who catch what nobody remembers until launch week.
That is the test the handover is designed for. You get a runbook, a data dictionary, commented migrations and a recorded walkthrough, written while we build rather than in the last week. Then we stay reachable on a small retainer if you want it, and we are equally fine if you don't need us.
Usually, but not blind. We read the codebase first and charge for that read, then tell you honestly whether finishing it costs less than restarting the parts that matter. Sometimes the answer is restart, and we've said so to people who wanted to hear otherwise. Half-built systems hide their debt in the parts that look done.
Related services
More in Custom Software & SaaS.
Let's map the workflow before anyone writes a line of code.
Bring the spreadsheet everyone actually works from. That document is the real brief, and 30 minutes with it tells us more than a requirements doc.