Building ChatBSC

Using AI agents to build a product in a few hours

Recently, I spontaneously decided to try the new version of the Replit Agent. If you’ve not heard of it: it’s an AI agent that writes code. I presume it uses Claude 3.7 sonnet under the hood.

But what should I have it build?

A few months back, I was in Las Vegas for the annual ISSA trade show. This is an annual worldwide conference for the cleaning industry. Since OrangeQC’s product is a quality control platform for facilities teams, it’s a big deal for us. One of our major customer segments is Building Service Contractors, which means the commercial cleaning companies of the world.

(It’s a big deal. These people keep our world clean. We respect the hell out of them.)

While I was there, I attended a panel on AI. This was essentially a small group of commercial cleaning company general managers who talked to the room about how they used ChatGPT in their daily operations. None of it was new to me, but it was very interesting to hear them discuss the specific prompts they use, and the use cases. Very different than anything I did as a technologist - employee training, scopes of work, RFPs, customer responses, and so on.

Separately, I’d heard Claire Vo on Lenny’s podcast discuss her side project ChatPRD. When it launched, I remember it being sorta slammed by some people as “just a GPT wrapper”. It’s an AI assistant for product managers, aimed directly at saving them time w/ document templates and presumably some specialized system prompts, with other valuable features on top like document editing and so on.

But it seems that GPT wrappers may actually be much more defensible as products than we initially concluded.

You can see where this is going.

Replit Agents, ISSA, and ChatPRD combined in my head to produce ChatBSC.

Use Case & Target Customer

The goal is to help GMs of commercial cleaning companies save time by providing a simple interface w/ options and templates for common scenarios. With a finely tuned system prompt + a preset first message, using the assistants API instead of the completions API (so that the threads will remember details and context), it currently supports the following presets:

• Staffing and scheduling challenges

• Suggestions for improving inspections scores

• Writing contract proposals to win more business

• Developing new staff training programs and content

• Crafting responses to client and team emails, text messages, etc

• Figuring out how to optimize operations using data from the business

This is just the first pass. There are lots of other little scenarios that I fully anticipate this product will serve going forward. I’m very eager to learn more about how people use it.

Building ChatBSC: My Process

I started with a PRD. I had ChatGPT o1 do some research and then I fed it into ChatPRD to produce the requirements doc. I edited this quite a bit and then asked Claude to produce a short technical document outlining how the product should be built - what technologies to use, dependencies and assumptions, and so forth.

Out of that, I got a prompt that included both documents and fed it all into Replit.

It got the broad strikes right after one prompt. 🤯

Now, just like if I were talking to an engineer, I didn’t scope it all out right at the start. It was missing a lot. But, it had auth0 authentication working and it stored everything in firebase. I could sign up, start chatting, and save documents. It worked.

So then I essentially layered on more features. Account limits and stripe checkout integration. Preset options to start chats. Rendering markdown documents as PDF for download. And so on.

Did it get everything right immediately? No. But neither do most engineers, myself included. Everything takes a few iterations.

I can’t stress enough what an eye opening experience it was to build this product. Even though I’m a technical person, I didn’t write a single line of code. I essentially treated replit as an experienced engineer. This means I assumed it knew what I meant by “best practices”, “code maintainability”, “ease of future change”, “separation of concerns”, and so on. These are important regardless of who/what is doing the building.

I even tried once to ask it to prevent future problems by identifying the top three areas of tech debt, areas of the codebase that resist change. We picked the top contender after an iteration and refactored it without changing the app’s behavior. Was this worth it? Hard to tell. Hard to measure. Just like cleaning up tech debt on a project with a team of engineers.

Cost

This is the game changer. In just a few hours of work across two evenings, I spent a grand total of $21 building this product - deployment costs being separate. (And the replit deploy process is terrific!)

Think about that. Instead of building this thing for weeks on nights and weekends as a side project, I had it ready for real users to try in hours, and for a fraction of a fraction of the cost it would normally require.

What’s next?

The hardest part is always distribution. And now that I’ve only invested hours into this project, I can start to find users much earlier. I can learn and iterate much more rapidly.

If nobody wants this? No biggie. I’m only out $20 and a few hours of work.

What’s occurred to me now is that I could do this every week. Each week I could launch a new product.

I’m no longer constrained by time - I’m constrained by my choice of what to build.

What a game changer.