Can I Sell This?

It Works. Now Someone Wants to Pay for It.

It's late. The thing you built is running. You've used it every day for months, it does exactly what you needed, and it hasn't fallen over.

Then someone asks what it costs. Or you're looking at a half-built pricing page with the cursor sitting in the price field.

And a question arrives that never came up once during the entire build: is this safe to sell?

Nothing changed. No bug appeared. The question just showed up on its own and now it won't leave. Sound familiar?

That question isn't imposter syndrome, and it isn't a sign you did something wrong. It's a real question and it's the right one. It just isn't the question you probably think it is.

First: You Built It

Let me be clear before anything else, because most writing on this topic hedges here, and the hedge is the tell.

You built it. It runs. It does the job. What used to take a team and a quarter took you and a few weekends, and that's not a lucky accident or a toy. It's the thing itself.

I'm not going to tell you the code is probably fine, but. There's no but. You shipped. Shipping is the part most projects die before reaching, and you did it.

So this isn't about whether you were good enough to build it. That's settled and I'm not revisiting it. It's about what changes the moment money moves.

Shipping to Yourself and Selling to Strangers Are Different Acts

This is the shift, and everything else follows from it:

Shipping something to yourself and selling it to strangers are not two difficulty levels of the same act. They are two different acts.

When you were building for yourself, it works was a complete and sufficient standard. Genuinely sufficient. If it broke, you fixed it. If it lost something, it was your something. If it was down on a Tuesday, you shrugged and did that one thing by hand.

The moment somebody pays you, you have made representations. Not because you wrote them down. Because that is what taking money means. You've said something about their data being safe. Something about the thing being there tomorrow morning. Something about what happens when it breaks, and who fixes it, and how fast.

You may never have typed a word of that. Doesn't matter. A customer heard it anyway. And somewhere underneath, so did you, which is exactly why the question showed up at 2am.

Before: it works, therefore it's done. After: it works, and now, for whom, holding what, and what happens when it doesn't. Same software. Completely different set of obligations.

There's a Lowe's Down the Street

There's a Lowe's down the street. You can buy a replacement outlet for a few dollars, watch a video, and swap it out in fifteen minutes.

That advice is correct. I want to be generous about this, because it's true: the task really is simple. Millions of people do it every year and nothing bad happens. The people telling you to just do it yourself are not wrong.

And you can still be very badly hurt.

Not because it was hard. It wasn't hard. Because nobody mentioned the breaker.

The risk was never in the difficulty. It sat in one prerequisite that anyone experienced considers so obvious they forget it's a step. The video skipped it because the person filming has killed power ten thousand times and it stopped registering as an action years ago. It isn't a gap in your ability. It's a gap in what got said out loud.

Except Software Has No Inspector

Now the part where the analogy breaks, and the break is the sharp bit.

Electrical work comes wrapped in an entire apparatus you didn't build and don't think about. Codes. Permits. An inspector who shows up and red-tags a panel. And above all, a breaker that trips instantly, loudly, at the exact moment of the mistake.

That's feedback. Fast, cheap, impossible to miss. It's the actual reason ordinary people doing their own electrical work is mostly safe. Not talent. The system tells you immediately that you got it wrong, and you go fix it before it matters.

Software you built yourself has none of that.

There's no inspector. Nobody issues a violation for a permissioning mistake. Nothing trips when one customer can read another customer's records. The app doesn't slow down. No red text appears anywhere. It keeps working, silently and incorrectly, at full speed, for as long as nobody happens to look.

You find out in month nine. Usually from someone else. And by then it isn't a bug anymore, it's a disclosure conversation, and you're having it with the customers who trusted you.

The absence of a feedback mechanism is why people don't self-correct. Read that as an engineering statement, not a moral one. No signal, no correction. That's true of everyone, including people who do this for a living, which is precisely why the profession built artificial signals: staging environments, code review, alerting, audit logs, someone else's eyes before it goes out. All of that is scaffolding for a breaker that does not exist on its own.

Care doesn't substitute for it. Neither does competence. You cannot be careful about a thing that never told you it happened.

What You Didn't Get Asked

The mechanism is structural.

AI answers questions extremely well. That's the thing it does. You asked for a login, you got a login. You asked for billing, you got billing. Every answer was reasonable. Every answer worked.

But you got answers to the questions you asked. Nothing in that loop raises the ones you didn't.

You didn't ask what happens when two people touch the same record in the same second. You didn't ask who can see whose data when there's an ID in the URL and somebody changes the number. You didn't ask what happens when the payment provider times out after charging the card but before your app hears back. You didn't ask what you are legally holding the moment you store an email address, or where it lives, or what you owe someone who writes in and asks you to delete it.

Not because you were careless. Because those questions never came up. They don't come up while you're building. They come up after you've watched them go wrong, and then they come up forever.

That is not a competence gap. It's a question-supply problem, and it's fixable in an afternoon.

The Questions to Ask Before You Charge

So here's the useful part. Ask these before you take money. Most of them you can answer yourself today, and every answer leaves you better off whether or not you ever talk to another human about it.

• Who can see other people's data? Make two accounts. Log in as the first one, find an ID in a URL or a request, change it to the second account's, and see what comes back. If it comes back, you found it in five minutes instead of month nine.
• What happens if the database is gone tonight? Not corrupted. Gone. Do you have a backup, when did you last actually restore from it, and how long did that take? A backup you have never restored is a belief, not a backup.
• What did you promise in writing? Read your own landing page as if you were a customer who just lost a week of work. Every line about security, privacy, uptime, or "your data is safe" is a promise you now have to keep.
• What breaks if fifty people arrive at once? Not a hypothetical growth curve. One good post, one newsletter mention. Do you know what falls over first, and would you find out from a dashboard or from a customer?
• What happens when a dependency goes down? Payments, auth, email, the model API, whatever you're calling. When it's slow or returns an error, does your app tell the user something true, or does it show a blank screen and quietly lose the transaction?
• What's the worst thing a user can do by accident? Delete something unrecoverable. Get charged twice. Email the wrong list. Find the one path that's genuinely expensive to undo and put a real guardrail on it.
• Who gets the call at 3am, and what can they actually do? If the answer is you, and you're on a plane, that's your answer. Write it down anyway. Vagueness here is how a two-hour outage becomes a two-day one.

None of these require you to open the codebase and pass judgment on the quality of your own code. They're not about code. They're questions about consequences, and consequences are exactly the thing you can reason about better than any tool can, because you're the one who knows what your customers actually rely on.

Some of these will already have good answers. Genuinely, some will. The list that matters is the one where you read the question and realize you have no answer at all, not a bad one. That short list is your real work, and it's usually much shorter than the fear suggests at 2am.

---

The bottom line: you can absolutely sell it. Selling is just a different act than building, with a different set of obligations that attach the second money changes hands. The questions that come with it aren't questions you failed to answer. They're questions nobody ever asked you.