MODULE 6

Now What?

Maintain, improve, and keep shipping.

Spoons: Low

Time: 15–25 min

Done when: you have a simple next-steps list and a maintenance plan.

You shipped an app. It's live on the internet. Real people can use it.

Now comes the question everyone asks after their first deployment: what do I do now?

This module is about life after launch - how to maintain what you built, how to make it better, and how to think about what comes next.

The Identity Shift

Here's the thing that changed when you deployed that app: you're no longer someone who wishes they could build things. You're someone who builds things.

That's not a small shift. That's a fundamental change in what's possible for you. Every idea you have from now on comes with a new question: "Could I build this?"

The answer, more often than you'd think, is yes.

What you proved: You proved you can take an idea from "wouldn't it be cool if..." to "here's the link." That's a superpower. Most people will never do this. You did it once, which means you can do it again.

Maintaining Your App

Your app is live. But "live" doesn't mean "done forever." Here's what ongoing maintenance looks like:

Things that might need attention:

Users report something broken (fix bugs as they come up)
You notice something that bothers you (fix it or add it to a list for later)
A dependency needs updating (Claude Code can help with this)
You want to add a feature (see next section)

The realistic maintenance schedule: For a simple app with a few users, maintenance might be: check it works once a month, fix things when users complain, update it when you feel like it. You don't need to obsess over it. If it works, it works. One important note: periodically check if your app's dependencies (the code libraries it relies on) need security updates - Claude Code can help identify and apply these updates.

When someone reports a bug:

A user reported this issue: [describe what they said]

Can you help me figure out what's wrong and fix it?

When you want to check if everything's working:

Can you review the current state of this project and let me know if there are any obvious issues or things that need updating?

Adding Features

Version 1 is live. Now you're thinking about Version 2. Here's how to approach adding features without breaking what works:

The Feature Addition Process

1. Write down what you want to add (be specific)
Don't say "make it better." Say "add a way for users to save their favorites" or "add a dark mode toggle."

2. Ask Claude Code to add it
Describe the feature clearly. Reference what already exists. Ask Claude to preserve existing functionality.

3. Test the new version locally first
Make sure both the new feature AND the old features still work before you deploy.

4. Deploy when it works
Push to GitHub, let Vercel auto-deploy, check the live site.

Adding a feature (template):

I want to add a new feature to my app.

The feature: [describe what you want]

Please:

1. Don't break any existing functionality

2. Show me what you're changing

3. Let me test it before we push to GitHub

When Things Break

Something will break eventually. A user will find a bug you didn't. An update will cause issues. The site will go down. This is normal.

Don't panic.

Here's your debugging process:

Figure out what's actually broken
Is the whole site down? Is one feature broken? Does it only break for certain users? Get specific.
Check if it's your code or the hosting
Go to Vercel dashboard. Is there a deployment error? If Vercel says everything's fine, it's probably your code.
Ask Claude Code for help
Describe what's broken, paste any error messages, let Claude investigate.
If Claude can't figure it out: roll back
Vercel keeps every deployment. You can click "Redeploy" on a previous version to restore a working state while you figure out what went wrong.

The rollback is your friend: If you deploy something and it breaks, you can always go back to the previous version in Vercel. This means you can experiment without fear. Worst case, you click one button and everything's back to how it was.

What to Build Next

You've got the skills now. You've got the setup. The question is: what else could you build?

Good candidates for your next project:

Something that solves a problem you personally have
Something that solves a problem for your business
A tool you wish existed but doesn't
An improvement on something that exists but sucks
Something that automates a repetitive task
A simple version of something complex

The best projects: The best things to build are things you'll actually use. Not "wouldn't it be cool" projects that sit abandoned. Things that solve a real problem you face regularly. Those are the projects that teach you the most and actually get finished.

Ideas for what to build next: _______________________________________________

Growing Your Skills (Optional)

You don't have to learn more. You can build useful things forever with exactly what you know now. But if you want to level up, here are paths:

If you want to understand more
Start reading the code Claude writes. Ask it to explain things. You'll absorb concepts over time without formal study. No courses required.

If you want to build more complex things
Just try. Claude can build more than you think. Databases, user authentication, payment processing - ask and see what happens. The worst case is "we can't do that yet."

If you want to stop using AI
You could learn to code yourself. But honestly? Why? AI is only getting better at this. Your superpower is knowing what to build and how to communicate it. Let the AI handle the syntax.

The honest truth: You don't need to become a developer. You need to keep solving problems. The tools will keep getting better. Your job is to keep having good ideas and keep shipping. That's the skill that matters.

The Scripts You'll Keep Using

Quick reference for the conversations you'll have over and over:

Starting a new project:

I want to build [description]. I'm not a developer.

Start with the simplest version that works.

Create the files and let me know when I can test it.

Adding a feature:

I want to add [feature] to my existing app.

Don't break what already works.

Show me what you're changing.

Fixing a bug:

Something's broken: [describe the problem]

Here's the error message (if any): [paste it]

Can you figure out what's wrong and fix it?

Pushing an update:

I'm happy with these changes.

Can you commit and push to GitHub?

When you're stuck:

I'm stuck. Here's what I'm trying to do: [goal]

Here's what's happening instead: [current situation]

What should I try?

Your App Portfolio

Track what you build. Every shipped project is proof you can do this.

Project Name	Live URL	Date Shipped

Every line is evidence: Every project you add to this list is evidence that you can ship. When you doubt yourself, look at this list. When someone asks what you've built, you have answers. This isn't just tracking - it's building confidence.

Final Thoughts

You started this workbook with an idea. Maybe it felt impossible. Maybe you thought "people like me don't build apps."

You now have a live app on the internet. You did that.

The gap between "I have an idea" and "I shipped a thing" used to be years of learning to code. Now it's a conversation with an AI and a few button clicks.

This changes what's possible. Not just for this one project, but for every problem you encounter from now on.

See a tool that should exist? Build it.

Have a business idea? Prototype it.

Frustrated by something inefficient? Fix it.

The real skill you learned: The skill isn't coding. It's shipping. It's taking something from idea to reality. It's not giving up when things don't work the first time. It's iterating until they do. That skill transfers to everything.

Go build something else.

Workbook Complete

You finished the workbook.

You built an app.

You shipped it.

You know how to do it again.

You're a builder now.

Made with chaos and caffeine by The Unhinged Librarian

Now go build something else.