Team
Groundbase (Personal Project)
Shipped
2024
Tags
0→1
Founder
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 the code. It's a platform for owner-builders and contractors to manage budgets, track milestones, and handle draw requests in one place.
The problem
Building a home is one of the most financially complex things most people ever do, and the tools available to help are genuinely bad. Construction loans, draw schedules, contingency budgets, contractor coordination — most people manage all of it in a spreadsheet and a group chat. For a $400k+ decision, that's a real problem. Contractors aren't any better off. They're chasing approvals over text with no shared workspace.
"Do we build for owners, contractors, or try to serve both from day one?"
Early on I had to decide: do I build for the owner-builder or the contractor? Building for one is hard enough. Building for both means a completely different data model. I sat on this decision longer than I'd like to admit.
Both — with a role toggle that adapts the entire UX from the start.
The solution
One app, two roles, one shared data model. Owner-builders get financial planning and milestone tracking. Contractors get bid management and project status. The design is intentionally serious — dark palette, terracotta accents — because this is a tool for real financial decisions, not a consumer app.
What went right
Building the design system before any screens paid off — consistency was there from day one.
The role-toggle architecture created a natural network effect. Owners bring contractors. Contractors bring owners.
The nav pattern (bottom bar mobile, sidebar desktop) tested well with no explanation needed.
Tough spots
The draw management schema took three rewrites. It seems simple until it isn't.
Scope got out of hand fast — financial planning, milestone tracking, and contractor matching is a lot for one person doing both design and development.
Supabase auth + React Router took significantly longer than expected.
How we solved it
1
Person team
2
User types served
3
Data model rewrites
Start with the journeys
Before opening Figma, I mapped both user journeys end-to-end. Where do owner-builders and contractors overlap? Where do they split? The underlying data turned out to be almost identical — the views are where everything diverges. That insight drove the whole architecture.
Design system first
I defined color tokens, type, and spacing before designing any screens. It sounds like overkill for a solo project. It isn't — it's what let me move fast later without things falling apart.
Hardest thing first
Draw management was the most complex feature, so I built it first. If I'd left it for last, I would have had to rework a lot of what came before it.
Ship it
React 19, Vite, Tailwind CSS v4, Supabase, React Router v7. Bottom nav on mobile, sidebar on desktop. Deployed and in active development.
Lessons learned
Define the data model before you design anything. I skipped this on draw management and rewrote it three times.
Building for two user types at once is a lot. Validate one thoroughly before assuming the second will follow.
Solo 0→1 means no one's checking your work. Build in external feedback loops early.
Dark design systems require extra care on text contrast. It's not optional, budget the time.