Chapter 20: Layered Architecture
An important concept in software development, regardless of if you are writing the code by hand or you are using AI, is having a layered architecture for your application. Half of you probably just fell asleep reading that last sentence, but it’s actually a simple concept.
In general, there are 3 pieces to every application:
DATA
Visuals that make it easy to consume and interact with the DATA
The messy logic and plumbing that ties it all together.
Don’t fall asleep yet! Allow me one example to get my point across, and if you still don’t get it, you have my permission to fall asleep.
Open the weather app on your phone.
What is the app doing?
It’s showing you DATA about the weather forecast.
A really simple weather app might show you the weather forecast for a specific location, while other apps might have more advanced features that let you see what the weather is like across the country. The basic app and the advanced app are using the exact same underlying DATA—all that’s changing is how it’s being displayed. That is, the advanced app is showing the same DATA in a way that makes it more useful if you’re trying to find a beach to spend the day at.
Now suppose you were God. You might have a basic weather app that lets you set the weather for a specific day, but you can also pay $12 a month to be able to edit a bunch of days at the same time:
“Set a 7-year drought with the click of a button instead of manually setting 2,555 days of dry weather.”
The DATA manipulation is the same in both scenarios—paying for the monthly subscription just makes your heavenly life a whole lot easier.
Therefore, there is a clear separation between the underlying DATA and the visuals that make it easier (or harder) to consume and interact with it. This gives us our two main layers: DATA and visuals (we’ll discuss the messy logic layer at the end).
Why is this important to understand for vibe coding? I can just tell AI what I want, and it will make it for me.
Most people see apps this way: “I want it to do this,” “I want it to look like this,” and they don’t think about the underlying DATA at all. I think this is a really good mindset when you’re in the ideation/discovery phase of development because it tells the most compelling story about the problem you’re trying to solve, but when you start implementing, you have to start figuring out the details.
News flash: AI can’t read your mind. If you don’t fully understand what you want your app to do, AI will fill in the blanks. Again, this is really cool for rapid prototyping and seeing what’s possible, but, as you’ll soon find out, when AI fills in the blanks, it’s almost never what you actually wanted. You end up rewriting the entire app every time you want to make a change because you didn’t take the time to think through the problem at the start. This burns time and tokens.
I’ve found that the more effective approach is to start with the DATA, then everything else follows naturally from there. I’ve been working on a new app for RevenueCat’s annual Shipaton competition. If I had started by saying, “build me a time tracking app that helps people be more intentional with their time,” AI would have come up with something super cool, no doubt, but it would have been extremely difficult and time-consuming to rework the initial draft into something that was actually decent.
Instead, what I did was I asked AI to generate some idea images of a time tracking app called Void that had a space theme. With just a bit of context, it gave me back some really good ideas.
This is the ideation phase I was talking about—using AI to bring life to MY creativity.
Then, I pulled out a paper and pencil (yes, those still exist) and, you guessed it, I drew out the DATA model. This is fancy speak for the DATA the app needs to keep track of. For this app, the DATA is almost annoyingly simple:
Time block:
End time
List of tags
That is, each block of time that the user tracks has an end time (users track their time retrospectively—you don’t know what you’ve done until you’ve done it) and a list of tags (sleeping, working, shopping, etc.).
Once I had these two pieces, the visuals and the DATA, everything else flowed naturally from there. This is a bit of an oversimplification. There was definitely more planning, direction, and fighting with AI to get my way, but in general, separating the layers like this makes the problem much easier to reason through and puts you in the driver’s seat. Ultimately, AI should be a tool for building what you want, not for generating slop.
The layer I didn’t discuss here is all the messy logic that ties the DATA and visuals together. Not that this piece isn’t important, but this is the piece that will flow naturally, once you figure out what you want your app to do and what the DATA looks like.
Concrete Step #20: Build a new app and enter it to win Shipaton 2026 https://www.shipaton.com
Shipaton is an annual app development competition put on by RevenueCat during the months of August-September. I don't expect to win anything but its given me some much needed motivation to keep building and deploying.