Friction
- ↗There are no purpose-built financial tools for construction loan management.
- ↗Owner-builders make huge decisions with very little real budget visibility.
- ↗Owners and contractors often work from different versions of reality across texts and email threads.
My Role
- ↗Owned all of it: brand strategy, product thinking, UX design, and every line of code.
- ↗Built the design system from scratch, designed every screen, and shipped the whole thing solo.
- ↗Used React 19, Vite, Tailwind CSS v4, Supabase, and React Router v7.
Outcome
- ↗Created a role-aware product for both owner-builders and contractors.
- ↗Early users said they finally felt in control of their construction budget.
- ↗The draw approval flow cut down back-and-forth significantly.
Summary
I built Groundbase to solve a problem I kept running into: there are no good tools for managing the financial side of a home build. I designed the product from scratch and wrote all of the code for a platform that helps owner-builders and contractors manage budgets, milestones, and draw requests in one place.
The Problem
Building a home is one of the most financially complex things most people ever do, but the tools around construction loans, draw schedules, contingency budgets, and contractor coordination are still shockingly bad.
Most people manage six-figure decisions in a spreadsheet and a group chat. Contractors are not much better off either; they are often chasing approvals over text with no shared source of truth.
The Solution
The product is intentionally serious in tone because it supports real financial decisions, not casual task tracking.
Shared model, different views
Owner-builders get financial planning and milestone tracking. Contractors get bid management and project status. Both sides stay anchored to the same project data.
Tokens I had to live with
I was also the engineer, so color, type, spacing, and interaction rules got written as code I would have to maintain. That kept the system honest and small.
Serious UX for serious money
A dark palette, terracotta accents, bottom navigation on mobile, and a sidebar on desktop help the app feel like a real work tool instead of a novelty app.
The Process
Exploration
I sketched the timeline and budget panel first, because if those two didn't work together the rest of the app wouldn't matter.
Map both journeys first
Before designing screens, I mapped the owner-builder and contractor journeys end-to-end so the overlap and divergence points were explicit.
Write the primitives first
As a team of one, the primitives were the only leverage I had. Getting them right up front was what made every screen after cheap to build.
Build the hardest thing first
Draw management was the most complex feature, so I attacked it early rather than discovering late that the rest of the architecture needed to change.
Ship and keep developing
The app is deployed, in active development, and already generating feedback from real users managing real construction decisions.
Shipped
What is live today, with a real build running through it.