Port 3000 Is Not the Bakery's Problem: One Pre-Order App, Built Two Ways

A CLI called proc went up on Show HN this week. It finds and stops processes. proc kill :3000 ends whatever is listening on port 3000, after asking first. proc kill node --in . ends only the node processes in the current folder, not your editor's, and lists them and asks before it does. It's billed as agent-friendly, so the AI writing your code can drive it too.

It looks genuinely nice. Anyone who writes code has fought a leftover dev server sitting on port 3000.

It also got me thinking about the people who should never have to learn what port 3000 is. So I sketched one small app, built two ways.

The app

A neighborhood bakery wants whole-cake pre-orders for weekend pickup. Customers pick a cake and a pickup time, pay with KakaoPay or Toss Pay, and get a reminder email the day before. The owner checks the orders every morning.

It's a small app, and it's exactly the kind where writing it yourself gets expensive.

Built with code

A developer, or a determined owner with an AI coding assistant, would roughly:

• Set up a framework, a database and a local dev server (hi, port 3000)
• Write the order form, the orders table, and an admin page with a login so only the owner sees it
• Open a payment gateway account, put the keys in env files, and write the server code that confirms each payment
• Write a scheduled job for reminders and sign up for an email provider
• Pick hosting, set up deploys, point a domain, sort out SSL

All doable. The catch is that it doesn't stop at launch. Someone has to update dependencies, notice when a deploy breaks, and find out why Saturday's reminders never went out.

Built on DontCode

You describe the bakery to Insight, our AI. The first build is the landing page, and on your first project it's free. Features come after that, one build each, and you see an estimate before you press Build.

Most of the code list is already done:

• Card, KakaoPay, NaverPay and Toss Pay are in every project's checkout. The only thing to fill in is the payout account.
• Orders land in a table you open like a spreadsheet on the Database page, with search, filters and CSV export. That might be the whole admin page.
• Email is built in. The day-before reminder is a scheduled job: pick a schedule, describe what it sends.
• There's no deploy button. Every finished build goes live at a permanent URL with SSL, and on Pro it has to pass its checks first.
• History keeps every change, with Undo and Restore for when one goes wrong.

The owner never sees a port, a process or an env file.

When code still wins

If there's a developer in the family who enjoys this stuff, code gives you total control. Same if the app needs something odd, like talking to an old point-of-sale machine in the back room.

For "take orders, take money, send reminders," though, writing it from scratch mostly buys you a second job maintaining it. The bakery's job is cakes.

A quick test before you choose

List every step your app needs and mark each one: is this my business, or is this plumbing? If it's mostly plumbing, use a platform. If what makes you different lives in the plumbing, write code.

proc is a good tool for people who live in a terminal. For everyone else, the best tool is the one where a terminal never comes up.

If you've got a pre-order idea of your own, try it on DontCode. The first landing page is on us.