<JB />
Joshua BusseyProduct Designer
LinkedIn
Work/Groundbase

Groundbase.

There are no good tools for managing a home build. So I built one. Yes, my house is also a stress test.

Project metadata
Client
Personal Project
Role
Founder / Everything
Team
Me, late at night
Shipped
2024
Type
Founder0→1
Result
1 house, 0 spreadsheets

Friction

Pain points for the customer
  • 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

What I owned during the process
  • 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

What I shipped
  • 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.
The TL;DR.

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.

Home building is still spreadsheet software.

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.

Key Decision
"Do we build for owners, contractors, or both from day one?"
Building for either audience alone would already be hard. Building for both changes the entire data model, which made this the foundational product decision.
The Decision
Build one app for both roles.
Use a shared data model with a role toggle so owners and contractors work from the same project reality while still getting the workflows each group needs.
Click to unlock →
One product. Two role-aware views.

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.

Design system before screens

Color tokens, type, spacing, and interaction rules were defined early so the product could move quickly without turning into a pile of one-off decisions.

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.

Solo 0->1. Built in the open.

The Process

Exploration

Exploration

Low-fidelity wireframes mapped the core layout and key interactions before any visual decisions were locked in.

Step 01

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.

Step 02

Define the system early

The design system came first because it was the only way to move quickly later without sacrificing consistency or burning time on rework.

Step 03

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.

Step 04

Ship and keep developing

The app is deployed, in active development, and already generating feedback from real users managing real construction decisions.

Shipped

The final experience, tested with customers and validated through iteration.

What worked. What got tricky.

Reflection

Tough spots
  • The draw-management schema took three rewrites before it felt right.

  • Scope expanded quickly because financial planning, milestone tracking, and contractor workflows all pull on each other.

  • Supabase auth and React Router took longer than expected to get right.

What went right
  • Building the design system before any screens paid off with day-one consistency.

  • The role-toggle architecture created a natural network effect between owners and contractors.

  • The mobile bottom nav and desktop sidebar pattern tested well without explanation.