Eret

A contractor can spend the whole day building someone else's project, then spend the evening reconstructing their own business from texts, spreadsheets, receipts, and half-finished notes.

That's the problem I'm building Eret around. As founder, I work across product, design, and engineering. Eret connects leads, estimates, proposals, jobs, and billing for contractors with between one and 50 employees. It also lets AI assistants help with the work, with permissions and approvals built into the operations they can use.

The product is in pre-production beta preparation. The central workflow is implemented and tested; getting it ready to hold a contractor's business records is still work in progress.

Carrying the information through the job

In a small contracting business, the owner may also be the salesperson, estimator, project manager, and collections department. A customer or project can end up entered into several different systems as the work moves along.

I wanted one piece of information to enter the business once and remain useful throughout the job. In Eret, a lead carries through estimating and proposals into a job. Materials move into purchasing, vendor bills update project costs, and completed work flows into invoices and payments. Each stage keeps its connection to the customer, scope, and financial record.

We mapped that journey across 22 product areas before building the production system. Then we built it in complete working slices: identity and organization boundaries, sales intake, estimates, proposals, jobs, and the financial work that follows.

Estimating is a good example of how much belongs in one slice. An estimate can use catalog items and assemblies, include waste percentages and allowances, and present the customer with different options. The quantities, costs, and customer-facing scope need to agree when that estimate becomes a proposal.

Eret runs as a TypeScript modular monolith, with a Fastify API, a Next.js web app, background workers, and PostgreSQL. Keeping the business rules together lets us follow a customer action from the interface through the API and into the database, including changes that touch several stages of a job.

Reviewing an assistant's changes

An assistant can inspect an estimate, identify questionable or missing lines, and prepare a revision plan. The person working on the estimate can refine that plan, approve the changes, or discard them.

We use the same registered operations for the interface and assistants. Each operation specifies who can use it, whether an agent can execute it, what needs human confirmation, and what goes into the audit trail.

Actions fall into three groups: agent-safe, confirmation-required, and human-only. An assistant's access is capped by the permissions of the person it represents.

For example, an external assistant can propose assigning a lead to another team member. Eret shows the approver the target, reason, risk, expiry, and proposed change. Approval allows Eret to execute that operation and record the result. It doesn't give the assistant general permission to make other changes.

Keeping money outside the model

Construction software has very little room for imaginative arithmetic.

Eret stores money as integer cents and performs pricing, markup, tax, waste, allowance, invoice, and payment calculations on the server. AI can help organize scope and draft descriptions. The application remains responsible for the amounts.

We applied the same separation to vendor-bill extraction. Confidence comes from the source evidence and arithmetic checks performed by the application. The model doesn't grade its own answer.

Testing a complete job

Testing the work through the application exposed problems that isolated tests had missed. In one case, a failed background handler could roll back the record of its own attempt. We found it by driving queued work through PostgreSQL.

We now test the whole sequence in the browser: create the lead, prepare the estimate, review the assistant's changes, send the proposal, open the customer link, approve it, and inspect the resulting job. Permissions, failure cases, and conflicting edits need to hold through that sequence too.

AI is also part of the development process. We give coding agents bounded assignments using product stories, operation contracts, and acceptance scenarios. Tests refer back to the stories they cover. That gives us a way to check generated work against the behavior we intended to build.

Before production, the remaining work includes infrastructure, backup verification, alerting, accessibility coverage, and final provider checks. Those are the next steps for the beta.