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

Getting a useful product into someone's hands matters. If AI helped you reach that point with less time and a smaller team, that gain is worth keeping.

A working product gives you something real to evaluate. It does not establish that every part of the code is correct, or that the product is ready for every customer. The next step is to check what people will depend on when you offer it to them.

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, you could make your own tradeoffs about reliability and support. You knew which rough edges to avoid and which tasks to do by hand. Even then, the consequences depended on what the software handled.

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.

Some Failures Look Like Success

A permission error can let one customer read another customer's record while every screen appears to work. A payment retry can produce a second charge while the interface shows a single confirmation. A backup can exist without being usable when you need it.

These are things to investigate, not assumptions about your product. Normal use may never exercise them. You need checks that deliberately examine the behavior people will rely on.

Tests, code review, monitoring, and recovery exercises make those failures easier to find. Which checks you need depends on what the product does and the consequences of getting it wrong.

What You Didn't Get Asked

A build can satisfy the request while missing something the customer will depend on. Ask AI to inspect those gaps, and check what it actually tested. Working features alone do not establish that access controls, recovery, and support are ready.

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.

Those questions can surface during building, through experience, review, or an AI-assisted investigation. Make space to ask them deliberately. Finding a gap may be quick; resolving it can take more work.

The Questions to Ask Before You Charge

Start with these questions before you take money. You can investigate many of them yourself, and every answer leaves you better informed. They are a starting point for evaluating readiness, not a certification that everything is safe.

• Who can see other people's data? In your own test environment, create two accounts with dummy records. Check whether the first account can retrieve or change the second account's records by changing an ID in a request. An unexpected success reveals a gap; a blocked request is one check, not proof that every access path is correct.
• 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.

Start with the consequences for your customers, then gather the evidence needed to answer each question. Some answers require inspecting code, exercising a failure, or bringing in a specialist. AI can help with that work. Your job is to check that the evidence supports what you plan to promise.

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.

---

Before you charge, establish what customers will rely on, how you have checked it, and who will respond when it fails. Resolve the gaps that matter for that use, and make promises the product can keep.