For those who’ve been with me from the start, I want to give you an update, maybe a recap of the last nine weeks and what I’ve learned building 20 apps in 20 weeks with ChatGPT and a friend. I’m also excited to share a pivot I’m taking based on what I’ve learned, what I think I’ve proved, and what I want to do next.
The Journey So Far: 9 Apps in 9 Weeks
Over the last nine weeks, I’ve built and released nine apps using ChatGPT to code. Now, I’m not a coder by any stretch of the imagination. I work as a technical product manager, but coding isn’t my forte.
The goal of the 20 apps in 20 weeks challenge was to prove that anyone can, with an idea, a bit of time and effort, and a modicum of technical skills, use ChatGPT to code and release a fully functioning minimum viable product (MVP) very easily.
Why I Took on This Challenge
I’m one of those people—and I hope you are too—who think they have great ideas every now and again. But I’ve either needed to find money to hire developers or learn how to code it myself. I never learned to code, and I didn’t have the money. I think a lot of people are in that situation, but they do have great ideas.
I always dreamed of having a big development agency with a room full of developers where I could come in, show the plan of what I wanted to build, and we could just build it. Now, with ChatGPT being released over the last 18 to 20 months, I don’t need that anymore. Literally, I can build an entire product in a weekend.
I think the last nine apps have proved that it’s possible. Now, let me tell you what I’ve learned along the way.
Lessons Learned Along the Way
1. The Power of User Stories in AI Development
Traditionally, when you build software, you go through these steps: ideation, then UI design, then you start to code the frontend, then the backend, or some variation of that.
In this situation, where I just wanted to solve one problem, I’ve eliminated any design step and gone straight to code. The reason I’ve done that is because of the tools that are available.
What I found is the key step when using AI as your developer is down to user stories, and that’s it. The better you plan your user stories, the faster you can actually get something output and coded. The AI can fill in the gaps a lot on UI, especially when you’ve used tools that will code UI for you. But it’s the user stories that you give it that get the output that make it really easy.
It’s really about knowing what the output is and then understanding the stories—the steps that people take. What’s the screen they see? What do they do on each step and on the page to get them to the output that you want?
This reliance on the stories—the journey, describing the journey—is, I think, the way that development will go. I won’t need to, and people won’t need to, actually write the code that delivers that output or that function—that will be unnecessary. But they will have to be able to describe it better.
I think the new coding language will be user story creation.
2. Focusing on Needs vs. Shoulds in MVP Development
The second big lesson has been about paring down the functionality you think your MVP needs. And this, for me, has been a hard one. I’ve always sort of over-scoped projects. But when you think about, “I want my users to be able to X,” what do they need to do to deliver that?
The keyword is need. What do they need to be able to deliver that? Not what do you want it to be, but what do they need.
An example would be in the Collectify app I built, which I think was app number five or six. Users needed to be able to create an account, create a listing with a name and a photo, make some settings, and do some basic organization on the page. Those are the needs, right?
When I was building, I spent time trying to organize—to give the user the ability to drag and drop. On the left in the sidebar, there’s all of their collections. And I thought, “Alright, they should be able to reorganize and drag and drop.” And the problem was, should is not a need. I spent a couple of hours messing around trying to make drag-and-drop work. Now that should wouldn’t have stopped someone from creating the collection; it wouldn’t have stopped someone from doing what they needed to do to get to the output of creating a collection of images and information that they can keep, store, and share.