I built the back office for my own contracting business. Here is what it does.

My back office is the private side of this same website. It holds clients, projects, photo galleries, and a document builder that produces estimates, invoices, and proposals. A finished document goes out as a share link, a web address with a secret code in it. The homeowner taps that link and reads the document. No account, no password. I write real estimates in it.

Key points:

• One Next.js app runs three public sub-sites on their own subdomains, plus the back office behind a login.
• The records are clients, projects, and photo galleries attached to projects.
• Estimates, invoices, and proposals come out of one document builder instead of three separate features.
• Share links carry a secret token, so the person reading a document never creates an account.
• The stack is Next.js for the site, Supabase Postgres for data, and Vercel for hosting. I picked all three because they are boring.
• The business it runs is mine, a registered Pennsylvania home improvement contractor, PA HIC #PA2199962. The public side is contracting.tdarby.com, and the version I build for clients is internal tools.

What the back office actually holds

Three record types carry most of the weight. A client is a person or a household, with contact details and a history. A project belongs to a client and holds the scope, the location, and the state it is in. A gallery hangs off a project. That is where a job gets documented: the condition before I touched anything, the framing before drywall hides it.

The document builder sits on top of those records. An estimate, an invoice, and a proposal share most of their structure. So I built one builder with different outputs instead of three features that would drift apart within a year. That decision felt lazy when I made it. It has been right every month since.

Then the share link. A finished document gets a token that becomes a web address I send to the homeowner. They tap it and read the estimate at their own kitchen table. Nobody gets invited to a portal or resets a password at nine at night.

Why the share link is the piece I would keep

If I had to delete every feature but one, the share link survives. The estimate template is replaceable, and plenty of software writes a decent one. What is harder to buy is a delivery path where the customer does nothing except tap.

I would rather say the downside out loud than let a client discover it. A token in a text message is not a password. Anyone holding that link can read the document. For a bathroom estimate that is the right trade. For payroll or personnel records it is the wrong one, and I say so when someone asks for the same pattern in a place that cannot take it.

What running my own software taught me about handoffs

Being the only user of a system I also wrote is a strange education. There is no ticket queue. I find the bugs myself, usually on a jobsite with dirty hands, so the cost of a bad design lands on me the same day.

The lesson I did not expect is that my own admin screens are too clever. They lean on conventions I keep in my head and never wrote down: what a project state implies, what a blank value means. I can run it fast. Nobody else could run it cold.

That is the same wall a client's office staff would hit on their first Monday without me. So the test I now apply to client builds is whether someone who did not build the system can finish a task without asking. Handoff documentation written by the builder tends to describe the code rather than the job. That gap stays invisible until somebody else sits down at the screen.

The honest limit is that I built for one user with one workflow. My back office has never needed role separation because there is nobody to separate from. It proves I ship and run working software. It says little about designing for several people with different roles.

Two other builds are the better reference. Volunteer Clinton County keeps every table in a dedicated Postgres schema, a walled-off part of the database. Row-level security limits the rows each person can see. There is a four-level membership hierarchy, and the database itself enforces the submission stages. GrantCue layers role-based permissions and multi-level approval workflows on the same foundation. Both are in the portfolio.

What generalizes to another trade

Plumbing, HVAC, electrical, and remodeling shops all quote differently, but the records underneath sit close together.

The part that never transfers is the quoting logic. That is the whole point of building rather than buying, and the reason I will talk somebody out of the project. If you write a handful of estimates a month and your accounting software's template covers them, custom estimating software is a bad purchase.

The case gets stronger when your quoting has structure specific to you. That might be assemblies, meaning bundles of labor and material you price as one unit. It might be an inherited spreadsheet with formulas nobody dares touch. It might be photo documentation that has to travel with the quote, or a second person who should be able to invoice without seeing every other record in the business.

Running my own version taught me which parts hold up when a job goes sideways, and which parts I added because they were interesting to build. A few of the second kind are still in there, and I know which ones.

Common questions

Can I buy the back office as a product?

No. It is not packaged for sale, and I do not run it as a service for other contractors. It is the reference build behind my internal tools work: the same stack and the same record shapes, rebuilt around how your shop quotes. The code itself gets written for your workflow.

Do I actually need custom estimating software?

Often not. If your accounting tool's estimate template covers the work and nobody on the crew is fighting it, spend the money on something else. Custom earns its place when the quoting logic is specific to your shop, or when a spreadsheet has quietly become the thing the business runs on.

What happens if we stop working together?

The repository and credentials transfer to you, with written handoff documentation and an admin screen for the settings that change often. The stack is conventional on purpose: Next.js, React, Postgres on Supabase, deployed to Vercel accounts in your name. Another developer can pick it up and read it without a tour from me.

Does a homeowner need an account to see a document?

No. The document gets a token, and that token becomes a link you send however you already talk to the customer. They open it in whatever browser is on their phone. The link is the permission, so anyone who has it can read that document. Fine for an estimate, wrong for anything sensitive.

The scope, the deliverables, and how I price a build like this are written out on the internal tools page. Your version would be shaped around how your shop quotes, not how mine does.