I designed and built a SaaS product in a day. It's... actually not bad.

The challenge

I've spent a lot of my career designing software.

Over time I've found myself increasingly interested in what happens immediately after the design is "finished".

How does it move?

What happens when the data is ugly?

What does the empty state look like?

What happens when there are 3,000 records instead of the six carefully selected examples in the design file?

What happens when somebody actually clicks the button?

The distance between designing software and making software has always fascinated me.

AI is making that distance considerably smaller.

So I gave myself a deliberately stupid constraint:

Design and build a believable SaaS product in 24 hours.

The goal wasn't to prove that a day is enough time to build production software. It obviously isn't.

The goal was to find out how much product thinking I could get into something when implementation stopped being such a significant constraint.

The setup

The nice thing about this experiment is that the tooling wasn't particularly exotic.

I used:

• Supabase for the database.
• Next.js and React for the product.
• Tailwind for styling.
• Tremor and shadcn/ui as references and component foundations.
• Cursor to help engineer the application.
• Vercel to put the thing on the internet.
• AI throughout to generate data, interrogate ideas, write code and move between design and engineering quickly.

The important bit is that none of these tools designed Barkhouse for me.

They shortened the distance between having an idea and being able to use it.

Here's roughly how I approached it.

Step 1: Find a problem with enough depth

Dog daycare.

Mostly because dogs are considerably more interesting than another fictional project management tool.

But it turned out to be a surprisingly good SaaS problem.

A daycare needs to know who is arriving, who is leaving, where every dog is, which rooms are full, whether vaccinations are current, who needs medication, what happened during previous visits, which owners haven't paid and whether Pickle the Dachshund is actually distressed or simply being Pickle the Dachshund.

There's scheduling. CRM. Healthcare data. Payments. Capacity management. Staff operations. Documents. Notifications. Search. Customer communication.

In other words, quite a lot of software hiding behind some very good dogs.

I called it Barkhouse.

Step 2: Build the database before designing everything

This was probably the most useful decision in the whole experiment.

I created a new project in Supabase, which gives you a PostgreSQL database without having to spend the first six hours remembering why your local Postgres installation hates you.

I modelled Barkhouse around real entities:

• Owners.
• Dogs.
• Locations.
• Staff.
• Rooms.
• Services.
• Bookings.
• Vaccinations.
• Feeding instructions.
• Behavioural notes.
• Incidents.
• Medications.
• Invoices.
• Payments.

Then I generated a synthetic dataset. Around:

• 3,000 dogs
• 2,000 owners
• 20,000 bookings
• 9,000 behavioural notes
• 12,000 invoices
• 300 incidents
• 6 locations
• 54 rooms

The important part wasn't generating lots of rows.

The relationships had to make sense.

A booking belongs to a dog. A dog belongs to an owner. That dog has vaccinations, notes and feeding instructions. A boarding stay can require medication. An invoice belongs to the customer who booked it. A room has a capacity and dogs currently occupying it.

Suddenly the interface had something real to push against.

A useful trick: create hero records

I also deliberately created a handful of customers with unusually complete histories.

Take Mabel.

She's a four-year-old French Bulldog.

She's been to Barkhouse dozens of times. Her owner is Sarah. Her Bordetella vaccination expires soon. She can become overwhelmed around energetic dogs. She needs medication at 18:00 when boarding. She has feeding instructions, behavioural history and an outstanding balance.

That's enormously useful when designing.

Instead of asking:

What should a dog profile contain?

I could ask:

What does somebody need to know about Mabel when she arrives this morning?

That's a much better design question.

Step 3: Don't design a dashboard

The easiest version of Barkhouse would have been a sidebar, four statistic cards, a graph and a table.

Revenue up 12%. Bookings up 8%. Perhaps a tasteful gradient.

We've all done enough.

Instead I asked:

What does someone running this business need to know right now?

• Who is here?
• Who is arriving?
• Who is leaving?
• How full are we?
• Does anything need attention?
• What happened recently?
• What needs doing next?

That became Today, the operational centre of Barkhouse.

This distinction mattered.

I wasn't designing a place to display the database.

I was designing a place to operate the business represented by the database.

Step 4: Establish the visual rules before asking AI to build screens

This was another lesson learned very quickly.

Tell an AI coding tool to:

Build me a beautiful modern SaaS dashboard.

And somewhere in the world another four KPI cards are born.

Instead I gave Cursor fairly opinionated rules.

Barkhouse should feel somewhere between the warmth and photography of Airbnb, the precision of Linear, and the data presentation of products like Tremor and Attio.

Warm, but not cute. Dense, but not exhausting.

No paw prints everywhere. No cartoon dog mascot waving from the empty state. No giant gradient cards informing me that revenue is up 4.8%.

Photography became part of the information architecture.

Dogs should be recognisable by face throughout the product.

That meant the same photograph follows Mabel through search, bookings, rooms, alerts and her profile.

When there are 40 dogs in a building, that isn't merely decoration.

It's useful.

Step 5: Give Cursor rules, not vibes

I used Cursor heavily to engineer Barkhouse.

But rather than repeatedly prompting:

Make this nicer.

I gave it a product specification.

• The stack.
• The database structure.
• The information architecture.
• Component principles.
• Interaction principles.
• Photography treatment.
• Motion rules.
• What should happen when a dog is selected.
• What the Today screen should answer.
• What I explicitly did not want it to produce.

Then I asked it to build a small part of the product first. App shell. Today. Dogs. Dog Profile. Search.

Only once those felt coherent did the rest of the product inherit the system.

That worked much better than asking AI to build twelve pages simultaneously and receiving twelve subtly different interpretations of border-radius.

Step 6: Design against the actual data

This is where building rather than prototyping became interesting.

The Dogs screen wasn't populated with John Smith, Jane Doe and Example User.

It contained thousands of records.

• Duplicate dog names.
• Missing photos.
• Long breeds.
• Dogs with no previous visits.
• Dogs with dozens of visits.
• Expired vaccinations.
• Outstanding balances.
• Medical warnings.
• Inactive customers.

Suddenly spacing decisions stopped being hypothetical.

Tables had to survive. Search had to work. Filters needed to be useful. Empty states actually happened.

The real object started exposing problems the picture wouldn't.

Step 7: Make the record feel like a story

The Dog Profile became one of my favourite parts of Barkhouse.

A traditional database interface might present Mabel as a collection of tabs. General. Medical. Bookings. Billing. Notes.

Technically correct.

Emotionally somewhere between Excel and filing your taxes.

Instead I treated the record as a timeline of Mabel's relationship with Barkhouse.

You get identity first. Photo. Name. Breed. Age. Owner. Current status.

Then what matters now. Vaccination warning. Medication. Care instructions. Outstanding balance.

Then her day:

• 08:03 Arrived.
• 09:12 Joined the group.
• 10:43 Behaviour note added.
• 12:00 Lunch.
• 18:00 Medication.

The database thinks in tables.

The person using Barkhouse thinks in dogs.

That became one of the main design principles.

Step 8: Make finding things almost embarrassingly fast

Once you've put thousands of records into software, navigation gets interesting.

So Barkhouse has global command search.

Hit ⌘K. Type Mabel. There she is.

Dogs, customers, rooms, bookings and actions can exist in the same search surface.

It's a relatively small feature that makes the whole product feel considerably more expensive.

Step 9: Design the beginning too

I nearly stopped once the core product worked.

Then I realised I'd built the classic portfolio SaaS project.

Somehow the fictional company already had 3,000 dogs and everybody knew exactly how to use the software.

So I designed onboarding.

And it became one of my favourite parts.

Barkhouse starts almost like a hospitality product:

Run the place they can't wait to come back to.

Then it gradually builds your business.

• What should we call your daycare?
• Where is it?
• What services do you offer?
• Where do the dogs spend their day?
• Add your first dog.
• Import your customers.

Each stage has its own simple illustration derived from the Barkhouse identity.

The interface starts empty and gradually becomes your Barkhouse.

The onboarding isn't just gathering configuration.

It's teaching you how the product thinks.

Step 10: Put it on the internet

Once the application was working locally, I connected the project to Vercel.

The Supabase environment variables live in Vercel rather than the repository.

Push. Build. Deploy.

Suddenly the thing that hadn't existed that morning had a URL.

This part still feels faintly ridiculous.

AI changed the speed, not the decisions

Obviously I didn't manually type 20,000 bookings into PostgreSQL while staring heroically into the middle distance.

AI did a considerable amount of implementation work.

It helped generate the database, write code, build components, troubleshoot errors and iterate.

That's precisely what made the experiment interesting.

When producing something becomes dramatically cheaper, you can spend more time deciding whether it should exist in the first place.

I could try an interaction. Use it. Decide it was rubbish. Change it.

I could populate an interface with thousands of records rather than six perfect examples.

I could move between product design and engineering without treating them as two completely separate phases.

The interesting part wasn't that AI wrote code quickly.

We've established that.

The interesting part was what happened to the design process when I could work directly with the thing I was designing.

Designing the object instead of the picture

This is probably the part I'm taking away from the experiment.

A static representation of software can hide an enormous number of problems.

The real object can't.

• The drawer has to open.
• The search has to return something.
• The long customer name has to fit.
• The empty state has to exist.
• The loading state happens.
• The database contains weird things.
• One component affects another.

Once you're designing the actual object rather than a picture of the object, those decisions arrive much earlier.

And I like that.

A lot.

Is Barkhouse finished?

Absolutely not.

It was built in a day.

There are things I'd redesign, interactions I'd push further, accessibility I'd audit properly, mobile states I'd spend more time with and approximately seventeen places where I'd probably change the spacing by two pixels because apparently this is how I choose to live.

I also wouldn't suggest anyone replace their actual dog daycare software with something I made between breakfast and an increasingly questionable bedtime.

But that wasn't really the point.

The point was to see what happens when the gap between designing a product and building the product gets very small.

In 24 hours I went from an empty database to a working SaaS product with thousands of interconnected records, an operational dashboard, search, customer records, bookings, health information, billing, onboarding and an actual visual identity.

And it's... not bad.

Which makes me considerably more interested in what happens when you give the same process a week.