Side projects are where I learn the most, even though they rarely make any money or get any users. I’ve built and shipped about a dozen small projects in the past two years, and I’ve gotten the process down to where I can go from idea to deployed app in 48 hours.

The key is ruthlessly cutting scope and using boring, proven technology. Every side project that died in my “projects” folder died because I tried to make it too complex or use it as an excuse to learn five new technologies at once.

Here’s my current stack for fast shipping: Next.js, TypeScript, Tailwind, Postgres (via Neon or Supabase), Vercel. That’s it. I use the same stack for every side project. No debates about frameworks, no technology evaluation paralysis.

Is this stack perfect for every use case? No. Is it good enough for almost everything? Yes. That’s the point. You’re not optimizing for the absolute best technical solution, you’re optimizing for speed and familiarity.

The first few hours are the most important. This is when I define what the core feature actually is. Not all the features the project could have. The single feature that makes it worth building. Everything else gets cut.

I use a simple test: can I describe the core feature in one sentence? “A tool that converts Markdown to social media posts.” “A search engine for design inspiration.” “A calculator for freelance project pricing.” If I can’t explain it in one sentence, the scope is too big.

Then I sketch the minimum UI. Literally sketch it on paper or in Excalidraw. I don’t use Figma or proper design tools because that’s a rabbit hole. I need to know what screens exist and roughly what goes on them. That’s all.

The typical side project needs 3-5 screens. Landing page, signup/login, main app interface, maybe a settings page. If I’m sketching more than five screens, I’m building too much.

Day one is mostly frontend. I scaffold the Next.js app, set up Tailwind, build out the core UI components. I don’t worry about data yet - everything’s hardcoded or uses dummy data. This lets me iterate on the UI quickly without dealing with backend complexity.

I use shadcn/ui for most UI components now. It’s not technically a component library, it’s just copying components into your project, but that’s fine. The components look good and handle most common UI patterns. I’m not trying to build a custom design system for a weekend project.

Authentication is the first backend piece. I used to build this myself, then I wasted countless hours debugging OAuth flows and password reset emails. Now I use Clerk or Auth.js. Pick one, follow the quickstart guide, move on. You can always change it later if the project gets traction.

Database schema design for side projects is simpler than real work projects. I usually have 3-5 tables max. Users, the main entity the app manages, maybe some metadata or settings. I don’t over-engineer relationships or worry about normalization too much.

I use Drizzle ORM because the API feels like writing SQL but with type safety. Some people prefer Prisma. Both are fine. The important thing is having some kind of schema definition and type safety between the database and application.

For the backend, I put everything in server actions or API routes. No separate backend service unless the project specifically needs it. The mental model is simpler when your frontend and backend are in the same Next.js codebase.

Day two is making it actually work. Connecting the frontend to real data, implementing the core feature, handling errors, adding loading states. This is less exciting than building the UI but it’s where the actual value is.

I don’t worry about edge cases on day two. The happy path needs to work. Everything else can wait until there are actual users complaining about edge cases.

Deployment is the last step. Vercel for the frontend, Neon or Supabase for the database. Both have free tiers that are fine for side projects with no users. The whole deploy process takes maybe 20 minutes if you’ve done it before.

I set up a custom domain because projects feel more real with a real domain. Domains are $10-15 a year. If I’m not willing to spend $10 on a domain, I’m not serious about the project.

Analytics are optional but useful. I use Plausible or Vercel Analytics, whichever is easier to set up. I want to know if anyone’s using the thing, but I don’t need detailed conversion funnels or user session recordings.

What I explicitly don’t do: comprehensive testing, CI/CD pipelines, documentation, error monitoring, feature flags, A/B testing frameworks. All of that is useful for real products with real users. For a side project on day two, it’s premature.

The first version is always embarrassing. There are bugs. The UI is rough. Half the features I wanted aren’t there. That’s fine. The goal is to ship something that works well enough that one person could use it and get value.

Most of my side projects don’t get users. They sit there deployed with maybe five signups total (all friends I begged to try it). This is normal and fine. The point isn’t building a successful business, it’s learning and having something to show.

A few projects got some traction. My markdown to social media tool got featured on Product Hunt and had a few hundred users for a couple months before I shut it down. That was enough to learn about handling real users, dealing with scaling issues, and prioritizing features based on feedback.

The projects that worked best were solving problems I actually had. Building something because it seems like a cool technical challenge usually fails. Building something because you’re annoyed that a tool doesn’t exist sometimes works.

The 48-hour constraint is artificial but useful. It forces brutal prioritization. If a feature can’t be built in 48 hours, it’s not core to the MVP. It might be important later, but not for version one.

After shipping, I usually spend a few weeks on iteration if the project has any traction. Fixing bugs, adding the most-requested features, improving the UI. But if nobody’s using it after two weeks, I move on. No point polishing something nobody wants.

I keep all the code in GitHub, even for dead projects. Sometimes I’ll revisit old code and steal patterns or components for new projects. The code accumulates into a personal library of solved problems.

Side projects are also good for trying new things in a low-stakes environment. I learned tRPC on a side project, figured out React Server Components on another one, experimented with Svelte on a third. These experiments inform what I use in real work.

The mental model is different from client work or employment. In client work, you’re optimizing for maintainability, team scalability, long-term support. In side projects, you’re optimizing for learning and shipping quickly. Different constraints, different solutions.

I’ve met other developers who spend months or years on side projects, trying to make them perfect before shipping. Then they either burn out or the idea becomes stale. Ship early, ship often. Get it out there and see if anyone cares.

Most won’t. But the process of building and shipping is valuable regardless. You learn more from finishing and deploying 10 small projects than from endlessly polishing one big project that never ships.

The 48-hour constraint also helps with the emotional side. If I spend two days on something and it fails, that’s fine. If I spend six months on something and it fails, that’s demoralizing. Keep the time investment small and the stakes low.

My project graveyard is full of ideas that seemed good at the time. A Chrome extension for managing reading lists. A tool for generating social media content calendars. A price comparison site for web hosting. None of them worked out, all of them taught me something.

The current project I’m working on is a searchable database of design patterns with code examples. Will it get users? Probably not. Will I learn something from building it? Definitely. That’s enough reason to spend a weekend on it.

If you’re thinking about building side projects, start with something small. Don’t try to build the next big SaaS. Build a tool that solves one specific problem you have. Get it shipped in a weekend. See what happens. Then build the next one.