We sold the documents before we sold the software, and it was not the plan.
The plan was three Windows apps. What people can actually buy first is a small library of finance documents, Excel and Markdown packs, from USD 9.99, one licence you can use across a whole firm, modify or rebrand, and keep. No seat count and no renewal.
They shipped first for a boring reason. A document is done when it is correct. An app is done when it installs, updates, licences, survives a machine you have never seen, and can be supported by one person. The gap between those two definitions is months, and I had been treating them as the same kind of finished.
What it bought was not revenue. It was a real checkout, real files leaving, and a real licence question answered in public rather than in a spreadsheet. Every one of those is something I would otherwise still be guessing about on launch day for the apps.
The apps are still being built, and I would rather say what they are than promise when.
- Dictation for Windows that keeps your words on your machine.
- A tool that turns a folder of tenancy contracts into clean data.
- Double entry accounting software with a real general ledger and periods that close and stay closed.
For information and preparation only, not accounting, tax or legal advice.
The order-attribution point is the one I'd act on immediately, before finishing anything else. Across the handful of small paid products I've shipped, the biggest post-launch surprise was never demand, it was that the checkout and the webhook are two separate systems that can silently disagree: a payment can succeed while the record that says 'this person now has access' never gets written, because one event type wasn't wired into the webhook handler. Nobody sees an error, the customer just doesn't get what they paid for and eventually emails you confused. With a document pack that's a re-send. With the double-entry app it's someone's books not closing a period. Since you're already capturing which pack sold at checkout, I'd add one more thing at the same layer: a way to independently verify, days later, that every successful charge produced the expected downstream record, not just trust that the webhook fired. Cheap to add now, much more annoying to reconstruct after you've got real customers on the software side.
Fair point. Right now delivery sits with the merchant, so the gap is reconciliation on my side rather than the webhook.. The accounting app is where a silent success may hurt most, so that check goes in before it ships.
The bit I'd underline is that you've accidentally built the thing that gets found. Three Windows apps have almost no search surface, there are only so many ways someone types "double entry accounting software". A library of finance documents is hundreds of specific things people look up by name, and each one is a page. Typeform built most of their organic growth on exactly that shape, templates as the top of the funnel with the product sitting underneath.
Which makes the licence worth a second look. One licence, whole firm, modify or rebrand and keep is generous, and it means your files will end up circulating with your name off them. That's fine if the documents are the business. If they're the on ramp to the apps, you probably want something that survives a rebrand, even just a line in the footer or the file properties, otherwise the discovery you're building doesn't compound back to you.
Good call shipping them first though. A licence question answered in public is worth more than the 9.99.
The disappearing brand would be a real cost. Footer attribution is the version I am weighing, keep the pass on right, ask for one line of credit. If a buyer strips it, that was never a customer I was going to keep.
Interesting journey. I’m currently building a new social network in France focused on real-world positive actions, so I’m facing similar questions around early adoption. What was the most effective way for you to get your first active users?
Mine came off a site and a list that already existed, which does not transfer to a network. A network has no value at one user, so I would go narrow, one city, one interest, and get the first hundred talking to each other before opening it.
Real!
The psychological boost of early demand is also huge...seeing someone actually reach for their wallet on an "unfinished" or minimal version completely changes your mindset. It shifts you from guessing in a bubble to building with real momentum.
Validation Beats Perfection!
Thats an interesting perspective. Before the first order you argue about whether anyone wants it, after it you argue about what to build next, which is a much better argument to have..
This is the discipline I'd tell any first-time founder to steal. A document is done when it's correct, software is done when it survives a stranger's machine, and treating those as the same kind of finished is how launches slip for months. The real value of the $9.99 wasn't the revenue, it was watching a real person hit the licence question before you'd built support for it.
The useful part was the order of events. The license question arrived in public before I had the answer for it, and that is the page I would otherwise have written last.
Selling the packs first also gives you the boring post-checkout stuff early, which is the part people underestimate. Worth checking now: what happens when a card fails or a download link expires, and whether the buyer can re-download six months later without emailing you. With a perpetual firm-wide licence you'll get "we lost the files" requests forever, so a stable per-order download page beats one-time email attachments. I'd also start capturing which pack was bought against each order right at checkout — that's the data that tells you which of the three apps to finish first.
Agreed on the stable per order page rather than one time attachments. The pack is on the order line already, so the attribution exists. I have not yet let it decide which app I finish first.. it probably should.
The part I would nail down now is the licence, not the documents. What you shipped is perpetual, firm-wide, modifiable, no renewal. That is a generous model, and it also teaches your first buyers what buying from you means.
When the apps arrive, carrying install, update and support behind them, they will almost certainly need a different shape. If the document licence does not say in one line that it covers the documents and that software is licensed separately, that difference reads later as a downgrade rather than as two products.
Cheap to write today. Awkward to introduce after someone has bought both.
Thanks. This is the one I am acting on first. One line naming the documents as the covered work and stating that software is licensed under its own terms costs nothing today..and a worse conversation once someone buys both.
One refinement while you are writing that line: name the covered work by pack and version, not just "the documents". When you revise a pack next year, a buyer of the current one should be able to answer from the licence alone whether the update is theirs. That is the same boundary question as the software one, arriving a product earlier and costing a sentence to settle.
Thanks, versioning the pack list means the buyer can check eligibility without asking me. Going in with the licence wording.
The "definition of done" framing clicked for me. I'm building a portfolio of free finance tools (salary calculators, tax tools) and I spent weeks getting the first one live because I was treating "done" as "every edge case handled, every page enriched, ads approved." In reality I could've had the core calculator up in days and started learning whether anyone actually searches for it.
Your documents-first approach is basically what programmatic SEO people do without realising it. You shipped the smallest testable unit of value. For me that turned out to be the basic calculator page without all the extras. The extras can come once you know someone cares.
One question: are the document packs discoverable on their own (SEO, marketplaces) or are you driving traffic to them manually? Curious whether the demand signal came from organic search or your own audience.
Manual almost entirely and some through my website, that also tells me a warm audience will pay, and less about whether anyone types the query. Your calculator is the cleaner experiment on this point since search either shows up or it does not.
This is actually an interesting path. Sometimes selling the “manual” or knowledge around a problem reveals what customers really value before the full product exists. It’s a good reminder that the initial idea and the actual business can evolve differently.
Agreed.
the "a document is done when it's correct, an app is done when it installs, updates, licenses, survives an unknown machine, and can be supported by one person" distinction is one of the sharper reframes of MVP-scoping I've read here, most advice says "build less," this says "build the thing whose definition of done is achievable first," which is a completely different filter
makes me want to ask an uncomfortable question of my own project: what's the document-equivalent of an AI phone assistant, something with a much smaller definition of done that could still test real demand before the harder app-shaped problems (permissions, reliability, on-device execution) are solved. don't have a good answer yet, but it's a genuinely useful question to sit with rather than just pushing forward on the full build
curious if you're marketing the documents as a standalone product now that they're outperforming the original plan, or purely as a stepping stone toward the three apps still being built
The filter I use is which part of the value survives without owning the runtime. In your case that is probably the call handling or intent list, or decision tree sold as a pack?
The documents are their own line now rather than a stepping stone, sold through MOR platforms licensed separately from the apps which will be on distribution platforms.
"which part of the value survives without owning the runtime" is a genuinely better filter than what I was working with, thanks. applying it honestly: the intent-list/decision-tree idea is closer to it than I expected, a structured mapping of "here's what people actually ask their phone to do, and here's the exact plan StareBrain would generate for each one" doesn't need the runtime at all, no Android app, no execution layer, just the interpretation logic made visible
that's almost uncomfortably close to just... publishing my prompt engineering as a research artifact, which feels too thin to sell but might be exactly right for testing demand cheaply, similar shape to your documents outperforming the original app plan
good to hear the documents became their own real line rather than staying a stepping stone, that's a strong signal the MOR-licensed content itself is doing real, independent work, not just building goodwill toward the eventual apps
test is whether someone would pay for it with no runtime attached. If yes, publish it. and let it find the buyers before the assistant is ready for them.
That's a clean test, and honestly more direct than I was going to make it for myself. The uncomfortable part isn't building the artifact, it's finding out fast whether "no" means the idea's wrong or just that I haven't found the right five people to ask yet.
Going to try it: put together the intent-list/decision-tree as something a real person could evaluate cold, and see if anyone would pay before I write another line of Android code. If it's a hard no across the board, that's worth knowing now instead of after the runtime's built.
Appreciate you pushing this all the way to something testable instead of leaving it as a nice reframe.
I'd be curious to know if you're marketing your documents to one group, and your future app(s) to another group? You mentioned "one license across the whole firm", and I wasn't sure if that was one license for the documents, or one license for anything with your company name on it. I can see some nice synergy if people can buy in for one or the other, then "discover" the other and perhaps upsell whatever they don't yet have. But I can definitely understand the motivation to have something tangible to sell while you're building the slower stuff. Hope it takes off for you!
Thanks. I meant one license per document order, firm wide, covering the documents only. The apps will carry their own terms, because install, update and support change what license has to say. What I want to avoid is the second purchase feels like a restriction.
good read
thanks
The interesting part is that the document products gave you a real commercial test before the software was ready. A completed document can validate demand and purchasing behavior much earlier than a Windows app, which has a much heavier definition of “done.”
yes and this is what I underrated going in. A document's definition of done is a file, a proof read one, but a file. An app includes install, update, refunds and support. So the documents let me test price, copy and whether anyone reaches for a card at all, while the app was still a build. The demand signal arrived months before the software could have asked for one.
That’s an interesting contrast. The difference in what “done” means between the two products makes the earlier demand signal much more tangible.
and cheaper too.. a document that nobody buys costs a weekend. An app that nobody buys costs much more
That’s a useful distinction. I’d be interested in continuing the conversation beyond the thread — would you be open to sharing the best email to reach you on?