Replacing a Monthly SaaS with a Custom Construction Platform
An anonymized build note on replacing a monthly construction SaaS with a custom Next.js, Supabase, Invoice Ninja, Stripe, and n8n platform for a Northern Illinois service business.

This is an anonymized build note for a Northern Illinois construction business. The client name, customer details, addresses, internal documents, revenue, and private screenshots are intentionally left out.
The short version: the business was paying for a monthly app that covered pieces of the workflow, but not the whole operating system. The goal became a custom platform that could handle the public website, lead capture, client records, project status, invoices, payments, and automation without forcing the owner to stitch everything together manually.
The project is still moving through acceptance gates, so this is not a launch announcement. It is a look at how I think through a small-business platform when the work has to survive real operations, not just a nice demo.
The Problem
Small construction and home-service businesses often run on a mix of phone calls, text messages, spreadsheets, invoices, disconnected apps, and whatever the owner can remember at the end of a long day.
That works until it does not.
The business needed one place to answer practical questions:
- Who is the client?
- What property is the work tied to?
- What did they ask for?
- Is this still a lead, an estimate, an active job, or an invoice?
- Has the invoice been sent?
- Did the payment land?
- Who needs a follow-up?
- What happens if the owner misses a call or a form submission?
The old subscription tool helped with part of that, but the bigger opportunity was to build around the actual workflow instead of forcing the workflow into a generic tool.
The Build
The platform is built around five pieces:
- Next.js for the public site, dashboard, routes, and user experience.
- Supabase for the operational database, authentication, Row Level Security, and typed data access.
- Invoice Ninja for quote, invoice, and client billing workflows.
- Stripe for payment handling and webhook-driven payment reconciliation.
- n8n for lead intake, reminders, routing, and future workflow automation.
The public side captures trust and leads. The private side keeps the owner from losing track of people, jobs, invoices, and follow-ups.
The target architecture has three surfaces:
- A public marketing site that explains the services and captures new project requests.
- A client-facing path for invoices, payments, and basic project visibility.
- An admin dashboard for leads, clients, jobs, invoices, and operational follow-up.
What We Kept
The important decision was not "custom code everything." That is usually the wrong move for a small business.
Invoice Ninja stays in the stack because invoicing is a real product domain. It already handles quote-to-invoice flow, payment links, client records, and billing details better than a hand-rolled first version would.
Stripe stays in the stack because payment infrastructure is not where a small business should be experimenting.
n8n stays in the stack because workflow automation changes often. Lead routing, reminders, notifications, and replay logic are easier to iterate when the automation layer is visible and adjustable.
Custom code belongs where the business has its own shape: the public website, the lead form, the dashboard, the database model, the API layer, and the glue between systems.
What We Cut
The first version does not need every feature a construction platform could have.
The priority is replacing the paid app and making daily operations simpler. That means the early build focuses on:
- Lead capture.
- Client records.
- Property records.
- Job/project tracking.
- Estimate and invoice visibility.
- Stripe and Invoice Ninja webhooks.
- Basic dashboard views.
- Email/SMS follow-up paths.
- Operational logging and replay points.
Advanced analytics, report builders, deep role management, and more complex project-management features belong after the business is safely running on the core platform.
That is the difference between a useful platform and a forever backlog.
The Workflow Shape
A typical path looks like this:
- A visitor submits a project request from the public site.
- The lead is validated and stored.
- The client and property records are created or matched.
- n8n receives the lead event for notification and follow-up.
- The admin dashboard shows the new lead.
- The owner can move the lead toward an estimate or job.
- Invoice Ninja handles quote and invoice flow.
- Stripe confirms payment events through signed webhooks.
- The platform reconciles invoice/payment status and logs failures for replay.
The point is not to make the workflow impressive. The point is to make the workflow hard to lose.
The Hard Parts
The hard parts are not the homepage or the form.
The hard parts are operational:
- Making webhook handlers idempotent so duplicate payment events do not corrupt records.
- Keeping client, property, lead, job, invoice, and payment data consistent across systems.
- Designing the database so it can support the real business without turning every change into a migration mess.
- Making the dashboard useful to the person who actually has to run the business.
- Planning backups, monitoring, and restore procedures before the platform becomes business-critical.
- Avoiding scope creep while still leaving room for the next phase.
Those are the parts that separate "site build" from "business system."
What This Means for Similar Businesses
Not every small business needs a custom platform. A lot of businesses are better served by a good off-the-shelf tool and a cleaner website.
But custom starts to make sense when:
- The business already pays for multiple tools that do not talk to each other.
- The owner is doing the same follow-up work manually every week.
- Lead quality depends on service-area pages, reviews, and fast response.
- Billing, project status, and customer records need to stay connected.
- The business needs bilingual or local-market details that generic software does not handle well.
The question is not "can this be custom?" The better question is "where does custom create leverage, and where should proven tools stay in place?"
The Practical Lesson
The best small-business software is boring in the right places.
Use Stripe for payments. Use a mature invoicing tool for invoices. Use a real database. Use signed webhooks. Log the failures. Keep the first dashboard focused on the daily questions. Automate the handoffs that the owner forgets when the day gets busy.
That is the work I care about with HighEncode: local-business systems that are built and maintained, not just shipped.
When this platform clears its acceptance gates, I may write a follow-up with sanitized screenshots and a deeper breakdown of the dashboard, schema, and automation flows.
Want help applying this to a real business?
Use High Encode Learning for scoped work and cleanup. Keep davidtiz.com for my personal notes and experiments.
Related Articles
When a Small Business Actually Needs Automation
A practical way to decide whether automation is worth it: look for repeated handoffs, missed follow-ups, and owner-visible friction.
What I Check First on a Local Business Website
A plain first pass for local service businesses: what people see, whether they trust it, and how hard it is to ask for help.
About David Ortiz
Builder, writer, and systems-focused operator
High Encode Learning is the business-facing layer for the work behind these notes: services, demos, and implementation conversations grounded in systems thinking, browser behavior, AI tooling, and workflow design.