Assuming you have followed part 1 of this series, you now have a beautiful, customized development environment, waiting for you to start using it. In this second part, this is exactly what we are going to be doing. The flow of the post will follow one big prompt, that we are going to use to kickstart our application development process, and parallel to it, you will get to understand why the prompt is structured in the way that it is. Not only, but you will also get to understand the software development concepts around it.
If you did, however, miss the first part, here is a link to it:
How To Build Any Web Application (Part 1): Your Development Environment Let’s begin. Open your terminal emulator, go inside ~/Developer (‘cd ~/Developer’) if you are on MacOS, or inside ~ (‘cd ~’) if you are on Linux, and start tmux (‘tmux’). Split your panes, so you have two—one on the left, and one on the right. Focus on the left one and start Claude (‘claude’) or Codex (‘codex’), depending on which terminal agent you are using.
The Skill
Skill: [Github link]
Skills are just prompts that are consumed by your terminal agent, in a systematic way. The AI agent that you have in your terminal, is just an LLM, that passes its outputs into your terminal as commands, and reads the outputs of the commands it executes, which creates the magic that terminal agents present us with. While a prompt can be a simple “hello”, we are taking it a step further, going into the realm of context engineering, thus… taking the time to structure a prompt into a skill.
A standard, good foundation to structure your skills, is the following:
Set your intentions (shortly)
Expand on your intentions, essentially drawing a picture (broad)
Set a stepped plan of action
Expand on the technicalities; logically separate each logical block
Set your expectations for the way it does things
Add your expertise, continuing to build your expectations
Set a rule: arbitrary checkpoints
In our example, we have one “entrypoint” skill that later consumes a separate skill with all the details about our project. The entrypoint skill is stationed at [kubeden/skill.md], and the details skill at [kubeden/PROJECTS.template.md]. The detail-skill I use throughout this series is at [kubeden/PROJECTS.pastmonday.md].
Explaining The Skill
The prompt we have is very rich in opinions about how the agent should do what it should do. Let’s break it down. First, we have technologies, libraries, frameworks, and providers:
Technologies: Typescript
Providers: Vercel, Neon, Stripe
Libraries: tailwind, framer-motion, drizzle, stripe, font-awesome
Frameworks: NextJS
The reason we add specifics, is because of the way LLMs work. By adding specific keywords, we trigger specific LLMs pathways that allow the LLMs to more accurately “predict the next token”, which ultimately gives us a better result.
Here is a great talk about how LLMs work, and why being specific in your prompts produces better results: [link]
And to understand why I have chosen those specific technologies, we need to talk about the basics of web development.
Web Development
Web development is a domain in software engineering, which focuses on, well, the web! Meaning: primarily web applications that live in your browser. Translation: websites. This is as simple it gets: websites. For our series, we are going to look at three domains in web development: Code, Design, and Infrastructure.
Libraries & Frameworks
I just want to clear this out of the way first, because this is going to be related to all the following paragraphs. Libraries & Frameworks are just pieces of code, written by other people, that solve something we want to achieve. Something that we would’ve otherwise have to write the code for, ourselves. The difference between a library and a framework, is that a library is usually a smaller piece of code that does one thing, well, by itself, whereas a framework is a larger piece of software that (often) combines multiple libraries inside of it.
Code
All programming revolves around code. Code is the way we translate our “desires” into computer-understandable language. You create some files, which have a certain extension, in which you type certain words (syntax), structured in a certain way, which then get passed through a specific engine (compiler / JIT-compiler), and get sent to the very core of your machine. Your machine then understands what you ask it to do through the code you wrote, and it does it.
There are two main “areas of code”: Frontend, and Backend.
There is also a secret third area of code, called Full-Stack. This is usually a role where a single person writes both Frontend AND Backend.
Frontend
Frontend is the shiny colorful “end” you see when browsing websites. The colors, the structure, the animations… all of that is frontend. While this sounds fun (!), it mostly isn’t when you start hitting state issues, and have to calculate animation pixels. This is, fortunately, a thing of the past now. AI agents will do it for you.
Every website you see consists of HTML: the layout of the website, and CSS: the styling of a website. HTML is the skeleton, and CSS is the muscles.
In our prompt, what refers to as “frontend” is:
Tailwind (library for css styles)
framer-motion (library for animations)
font-awesome (library for icons)
NextJS (framework)
Backend
Backend is the “logic” of web applications. This logic is, by design, hidden from the user. You, as a user, are not supposed to understand what this backend does. For example! When you scroll a reel on Instagram, there are roughly ~3,400,000 lines of code being executed on Meta’s servers from the moment your finger touches your screen to the moment it had finished the scrolling motion and is no longer touching the screen. Without you knowing. Most of those lines are for tracking purposes. You are not supposed to know this. Because it is on their backend!
Mandatory: I made this number up, but if I had to guess, it would probably be somewhere up there.
In the context of our web application, when you think of backend, you are to think of the following functionality:
payments
security
“persistent” changes
authentication (users)
authorization (what information and actions can users see and do)
Usually, having a good, stable backend, is not an easy task. Mostly because database engineering in itself is a domain people get PhDs in. It includes database design, which requires a lot of mental effort to come up with optimized, sensible relationships, indexes, and functions. Fortunately for us, nowadays there are providers solving all of this for us. The one we are going to be using is called Neon. Neon is a DBaaS (translation: Database as a Service), and just recently they entered the BaaS (translation: Backend as a Service) zone. There are more BaaS providers out there, but my experience with Neon has been the best so far from all three I’ve used. Both in terms of performance, and responsiveness from their engineers. Also! When they release a new feature, I observed they usually first have it available through their API, which is a very nice benefit to have, due to the fact I can just ask my AI agent to implement it for me.
Speaking of APIs… an API stands for “Application Programming Interface”, and is a way for your code to interact with other code. In a way, an API is just a “communication layer” for machines. Which also makes it so powerful for AI agents — because they, in their core, are machines.
On AI agents being machines: take a look at [this talk] by Andrej Karpathy.
Also, on the topic of APIs, some are arguing all strongly profitable companies will become “agents-first” companies, essentially making their entire product offering available through their API. For which they charge, of course. Just something to think about.
In our prompt, what refers to as “backend” is:
NextJS
Neon (Data API)
Neon (Auth)
Drizzle
Stripe (Webhooks & Portal)
Design
What I realized, and proved to myself through experience, is that in order to make a web application look good and not vibe-coded, all you need to know is what design is in its core: a system of elements, all working together, where each element has its own purpose. Whether something is aesthetically good or not often depends on the context and desired end result.
For example, a beautiful website with tons of animations might look good to you, but it might look overwhelming and downright ugly for your grandmother who’s using her computer once a month.
Another example I can give is a car repair shop. You don’t put a ton of animations on a car repair shop website. Not because it won’t look good, but because the desired user base is simply not used to those websites looking good. They expect an almost PDF-like experience with the phone number up top and the shop’s availability. It’s best if the colors of it are red and white.
How you achieve this, is by separating UI from UX.
UI/UX
UI/UX stands for: User Interface / User Experience.
UI is responsible for the web application’s design system: Button sizes, Fonts, Colors, Border rounding, Letter spacing, Spacing in general, and so on.
UX is responsible for how the user is supposed to feel when using your web application. It includes: Pop-ups, User flows, More pop-ups, Redirects, Surprising offers, Not being able to read the rest of the blog unless they pay, and so on.
In a way, I like to look at UI/UX as an analogy to Frontend/Backend. UI is the frontend, and UX is the backend.
Common UI/UX terms
This section is very important, and is maybe 90% of the work when it comes to generating good UIs with AI agents. Knowing the terms. You need to know the terms. If you remember, this binds directly to the beginning of this post and the concept of “neural pathways”. Knowing the name of the terms, you can communicate with your agents in a way that they are going to understand, and more importantly—give you a website that does not look vibe-coded.
Here is a list of the most common UI/UX terms:
modal
sidebar
sidepanel
hero
footer
marquee
breadcrumb
button
alert
card
and more…
I strongly urge you to go and explore shadcn/ui’s components library: [link]
In our prompt, we mainly flood the AI agent with those terms, so that it can generate a good foundation for later, when we start building our landing page (and dashboard).
Infrastructure
Infrastructure is the area that handles where your web application lives. Servers. That’s the first word that should come to your mind when you hear “infrastructure.”
Servers are computers that run 24/7 with the only intention to keep a system up and running. In our case, you don’t really have to know all that much about infrastructure because we are going to use Vercel, who handle everything. But I think it is good to have some general knowledge, anyway.
Vercel is a PaaS (Platform as a Service) provider that have tens (hundreds?) of thousands (of millions?) of servers around the globe who handle everything there is to be handled for your web application to be up and running.
Without Vercel, you would have to provision a server yourself, install all of the required software on it, secure it, manage it, update it, and do all kinds of shenanigans to keep your web app up and running.
Another thing you will have to worry about in terms of infrastructure, is scaling. When your application starts getting many users (because it obviously will), your servers are going to start to crash. This will then force you into a cycle of manually upgrading your servers’ compute capacity, while thinking of ways to horizontally scale your hyper-successful SaaS. This will then introduce you to Kubernetes and containerization, where you will have to spend a few months of trial & error, while also shifting between the three main cloud providers: AWS, Azure, and Google Cloud. But! You don’t have to worry about that. Because we use Vercel. And Neon!
Databases
A database is both a part of infrastructure and backend. A database is the end result of your backend (meaning: your backend makes operations against a database), that lives on a server.
Databases mainly divide in two categories: SQL and NoSQL. SQL databases are relational, and are good for heavy applications, relying on lots of logic and relations between various backend tasks. NoSQL databases are non-relational, and are best for simpler, more local-first applications, where backend actions don’t necessarily need to rely on each other. Chances are, ~95% (number is a strongly convinced-in, personal estimation) of the times you build web applications, you will be using an SQL (relational) database.
I noticed NoSQL databases are great for applications that don’t rely on users interacting with each other. If your application is a simple tracker for example, you might very well just use a NoSQL database.
The two most famous SQL (relational) databases are MySQL and PostgreSQL. PostgreSQL is just a step above MySQL by having a tad bit more functionality and plugins available, with the one you are probably going to be most interested in being ‘pgvector’. One other reason we are using Neon, is that those plugins come natively available to enable without us having to install them (which… is pretty much what using an external vendor is for: having all those kinds of self-management tasks solved for you).
Running the prompt
Ok! Now that we went through a fair bit of theory, it is time to get practical. Go in your terminal, go inside ‘~/Developer’ if on MacOS, and ‘~/’ if on Linux, and create a directory named ‘pastmonday.com’. When inside this directory, enter ‘tmux’ and split your panes in half.
cd ~/Developer # if on MacOS
cd ~ # if on Linux
mkdir pastmonday.com
cd pastmonday.com
tmux
# <leader>+%
Now that you have your gun loaded (environment ready), start your terminal agent in the left pane:
# <leader> + h/{left-arrow}
claude # if you use claude code
codex # if you use codex
Get the prompt [link], paste it, and click enter.
Congratulations, you are now a web developer! Your AI agent will set the foundations for your project, with which you will be ready to go into the next part of the series, where you will be building the landing page for your application.
Closing
This concludes the second part of this 6-posts series. I hope you enjoyed it, and if you are unsure of anything, again—chat with your LLM of choice, or if you prefer human connection, feel free to chat with me on X/Twitter [link], or on my email.
In case you missed the first part:
How To Build Any Web Application (Part 1): Your Development Environment I can very strongly advise you to re-run the prompt in separate directories multiple times and see what results you are going to get. Chat with an AI before we continue, try to get somewhere on your own, and see how far you can go. If you end up building and deploying your application, congratulations! I’d love this for you. If not, do feel free to text me and share what stopped you from proceeding. I’d love to know, so I can better focus on it when progressing through the series.
Thank you for reading!
After-post notes
N1: All my posts are written by me.
N2: If this post inspired you to think, feel free to email me and start a discussion!
I love talking technology, and even so if you are, too, actively living in “the arena”.
You can find everything about me on denislavgavrilov.com/about
Thank you for reading and have a good one!