Six Weeks, No Team. My First Agent-Built Product

I just took a real SaaS product from a blank folder to a live, marketable service. On my own. In six weeks. No engineering team, no Figma-first design phase, no months of build. The thing I built is the sort of product I have watched five to ten person teams deliver over the course of months in my agency and consulting days. This time it was me and a coding agent, iterating directly in the browser, and the result is now out in the world.

This is the story of how that happened, what the product actually is, and why I think it has permanently changed how I am going to work.

Where this started

This follows on directly from my earlier experiments using a coding agent to rebuild my own website. That project convinced me the approach had legs, so I set myself a bigger challenge: build a product.

I had a backlog of ideas. The first one I reached for turned out to be a little too complex, and after hitting the same set of repeating problems a few too many times, I parked it and went looking for something more contained. That simpler idea is what became StreamDay.

StreamDay is a service for streamers to schedule what, when and how they are going stream, and communicate it clearly to their audience. It scratches an itch I have felt firsthand inside a few gaming communities, and the more I looked at it, the more I realised it was contained enough to be achievable but still complex enough to be worth doing.

The problem worth solving

The hard part, and the part I knew I had to tackle first, is group and shared streaming activities.

Right now, the way these come together is a mess. It usually starts as a group DM, descends into chaos, and eventually someone drops a link to a generic scheduling tool where everyone marks when they are free. Then somebody has to take all that collected availability and try to assemble an actual schedule out of it, which is followed by yet more back and forth to confirm what the schedule will really be. After all of that, you still have to solidify it and market it to your audiences ahead of time, so you can gauge enough interest to justify the extra effort a shared event takes.

These shared activities tend to take a few forms. Some are consecutive stream events. Others run back to back over multiple days, such as a stream weekend, which is a popular format.

On top of all of this, the gaming community is global by nature, so time zones complicate everything. There is the problem of the participants working out what times they are actually talking about between themselves, and then the separate problem of communicating the final plan back to an audience so each viewer understands when you will be live relative to their own time zone.

A digital version of this process is very well placed to solve all of that at once. Plenty of interesting technical and user experience challenges sit underneath it, which is exactly why it appealed to me.

The plan: prototype in code, not in Figma

I took a deliberately code-centric approach from the very start, and once again I did not begin in Figma.

I wrote some specifications, then went straight into coding a prototype in the browser, iterating there until I had something to react to. We got to a working prototype very quickly. It was wrong in almost every way, but I immediately saw the power of working like this. Being able to iterate on a live, functional thing from that point forward is far more useful than refining a static mockup.

So I kept iterating on the functionality, trying a couple of different layouts to land the core concept that would drive the main user experience. Only once that central view was roughly in place and working did I come to Figma, and even then not to draw whole pages from scratch. My process was to use an HTML to Figma plugin to import what I already had, pull it apart, restructure it, tidy it up, and then hand the cleaned-up output straight back to my agent to implement.

It was relentlessly iterative, and it worked.

What I actually built, week by week

Within two weeks I had a genuinely functional MVP. Within three I had a launchable one. Within four I launched my closed beta, once I had polished it enough to clear my own bar for what counts as launchable.

Then came a week of more aggressive testing with my closed beta audience. I fixed and amended fundamentals, and made a few top-level architectural changes I decided on after watching the product get used in situ.

The single biggest thing this first feature set had to get right was the live, shared nature of building a schedule together. When an admin assigns a slot, or a streamer marks their availability, everyone else looking at the event needs to see it move, immediately, without refreshing. That real-time behaviour is what kills the group-DM back and forth, and it runs across the availability grid, the schedule builder, and the public view all at once.

The other genuinely hard problem underneath the surface is time. Every participant and every viewer can be in a different zone, and the times have to stay correct through all of it, daylight saving included. All times added are stored in UTC, converted from the acting users defined timezone (set automatically with a user-override), and converted back for display for any given user viewing those times, changed instantly with an amendment to their globally accessible timezone settings. None of that is visible to the user, which is the point, but it is the part that quietly makes the whole product trustworthy and understandable.

In week six I moved on to the next major feature set: letting individual streamers plot out their own streaming schedules, regardless of platform. They can add streams manually through my tool, or pull them in automatically through the APIs of the services they stream on, and the result is a clear, shareable public calendar that tells their audience when and where they will be live. Every time and time format is customised for the time zone of whoever is viewing it.

That platform connection work brought its own twist. Pulling a schedule in from services like Twitch and YouTube means handling each platform's OAuth, storing credentials securely, and keeping events in sync in both directions. More testing, iterating and polishing followed, and by the end of the sixth week the majority of the functionality was in place, launched and marketable.

The irony is that the only thing actually holding me back at that point was not code at all. It was a Google Cloud authorisation process required before I could use their OAuth API openly. Until it cleared, the connection came with some fairly aggressive user warnings and a hard cap of one hundred users. That review took a few weeks. Now that it has been lifted, here I am writing this post and actively promoting the service.

A quick look under the hood

For anyone curious about the build itself, here is the high-level shape of it. StreamDay is a multi-tenant SaaS web app built on Next.js using the App Router, deployed on a single domain. The backend is Supabase, which covers Postgres, authentication, file storage and real time, all in one. There is deliberately no separate API server: the front end talks to the database directly through Supabase's client, and everything is kept safe by Postgres Row-Level Security policies that decide, per row, who is allowed to see and change what.

A few specifics worth calling out:

• Auth is Discord only, which fits the community this is built for.
• Real-time collaboration runs on Supabase's live channels. A change made by any one person propagates to everyone else viewing within a fraction of a second, which is what makes the shared scheduling feel alive.
• The time zone engine stores event times in the event's own zone and personal schedule times in UTC, then converts to each viewer's preference on display, daylight saving aware, on a fifteen minute slot grid.
• Platform integrations with Twitch and YouTube use each service's OAuth, with access and refresh tokens encrypted at rest (AES-256-GCM) and refreshed automatically before any sync.
• Payments run through Paddle as the merchant of record, which means tax, compliance and invoicing for a global audience are handled for me rather than being my problem to solve.
• Public sharing uses short, opaque share codes on a dedicated short domain, separate from the authenticated app.

It is, in short, a real product with real infrastructure decisions behind it, not a toy.

It's important to understand - this wasn't easy

I will emphasise the same thing I did with the website project: coding with an agent instead of with developers does not actually make the work easier.

You still have to make every correct user and design decision across the whole product process. You still have to make every correct product and technical infrastructure choice to support the features, performance and security a real service needs. There is an enormous amount of work in that. The savings are mostly in time and cost of development, because this is a full, end-to-end, agent-coded product, with the design process being accelerated thanks to skipping some now unnecessary steps - now that I'm empowered to do them myself directly in the browser.

The product also turned out to be larger than I expected, comparable in scope to projects I have seen delivered by teams of five to ten people over months, whether at my old agency, while consulting, or while advising other startups building similar things. I did it alone, in weeks.

How this has changed the way I work

This has shifted my perspective a lot, and the change is permanent.

The design process I am going to use from now on is to get to an operational prototype as fast as possible, then iterate directly in code, in the browser. Seeing fully functional results almost immediately and saving the detail and polish for later is far more efficient than designing everything up front in Figma, prototyping it, and then trying to test that.

I did still mock up a good number of pages in Figma for this project. Here is a screenshot of my entire Figma canvas, showing everything I produced to communicate specific scenarios to the agent.

But that canvas probably represents less than a quarter of the product, and less than a tenth of the various states, modals and messages that appear throughout it. Most of those pages are already out of date, because I have moved on and kept iterating and improving things directly in the browser. As always, Figma artifacts are just a reflection of a moment in time, and they go stale fast.

That raises some genuine questions about what the tool sets of the future look like. I think there will always be a place for something like Figma, but I am increasingly unsure what that place is unless these tools move further into the coding space themselves, producing functional output directly, or integrate far more tightly with what is happening in a local or production environments. Otherwise Figma simply becomes another design surface, which could be almost anything, where I lay something out creatively in order to reach the level of definition I need to communicate it back to an agent when words and prompts alone are not enough.

The part nobody has cracked yet

Doing all of this alone has been fascinating, and I have not yet had the chance to bring these skills into a team setting.

What is clear is that collaboration is the piece agentic workflows have not solved. Right now it is a very solitary activity between you and the agent. I think the first company to properly crack collaborative agentic workflows and problem solving is going to corner the market. Because make no mistake, this is a seismic shift in how our entire industry is going to work. It sits alongside the ones we have already lived through: desktop publishing taking over print in the 90s, the web taking hold in the early 2000s, mobile in the 2010s. This is the 2020s moment, and I am very much enjoying being part of it.

There is plenty of doom and gloom out there about what this means for careers. I feel the opposite. Everyone genuinely skilled in our industry is now able to do so much more, whether that means doing more inside a large organisation or working independently with their own clients. This new way of working is not something just anyone can do. You need the skills we have spent our careers building. If you have a firm foundation in the three pillars of product, user experience and engineering, plus real experience in product design and delivery, you should be able to pick this up.

I think we are heading from a world of a small number of software providers serving a large number of clients, towards a world of a large number of clients building and developing their own bespoke software, tailored to them, at lower cost. They are going to need a lot of people to help deliver it. I am happy to be one of them.

Please go check out the product. It's free to sign up and use. You just need a Discord account and there's a 30-day free trial if you find it useful enough to consider publicly publishing your stream links.

Where I am now

For now, I am delighted with what I have managed to do here. StreamDay is the first of what I hope will be many products I bring to market, and I am keen to see which of them I can scale and make successful. A well designed and great product does not a success make, getting into the hands of users at scale is the real challenge I face next. Alongside that, I expect to be doing client work in much the same way, both websites and products, to keep flexing these muscles and find out how far I can push them. I am already close to finishing my first client project, which I will share once it is up and running.

I do not think I have ever felt more empowered in my career than I do right now. My whole working life I have noodled with the idea of learning to develop, becoming an engineer, building and shipping my own things. That has now become real, without my having to spend the several years of hard graft it would otherwise have taken to get there, and that is exceptionally liberating. The only thing holding me back now is my own imagination and my own skills, and I am very happy to report that I feel I have plenty of both.

I cannot wait to share more once I have a few more projects under my belt.