A desktop product with licensing and payments
Not just an app, but everything that turns it into a product: keys, renewals, payments, updates and signed releases.
I answer within one working day, in writing. I never call.
When people come for this
- The tool exists inside the company and could be sold outside — but there is nothing around it: no keys, no payments, no updates.
- The work needs the machine itself: files, devices, local speed. A browser tab is not enough.
- Licences are handled by hand — keys in a spreadsheet, renewals in someone’s calendar.
- It must keep working offline, and still know its licence is valid.
What is inside
The app itself
For Windows, macOS or both, built to run on the machine rather than pretend a website is a program.
Licensing
Keys, activation, device limits, expiry and renewal — the part that decides whether a product earns or leaks.
Payments
Cards and cryptocurrency, renewals and refunds. Built end to end, not left as “connect a payment provider later”.
Updates
The app updates itself and checks what it downloaded before replacing anything.
Signed releases
Signature and checksum verified before a file is swapped, so an update cannot be replaced on the way to the user.
Automation interface
A local API and webhooks when the product must be driven by other tools rather than only by hand.
How the work goes
You describe the task
A short form: what the business does, what should change. No calls — I answer in writing, within one working day.
You get a quote
Within two working days, one figure for the whole scope, before any work starts. Not a range that doubles later.
You see the first screen
The opening screen as a layout, before anything is built. Wrong direction is cheap to fix here and expensive to fix later.
It gets built
Phone first, then desktop. Checked on a slow connection and on a real device, not only in a browser window.
It goes live
You get every access on day one: domain, hosting, analytics, the code. Nothing is held hostage.
What it costs
Desktop is priced by what surrounds the app more than by the app: licensing, payments, updates. One figure for the whole scope within two working days, before anything starts.
- Windows, macOS, or both.
- Whether licensing and payments are needed, or it is internal-only.
- Whether it must work offline and for how long.
- Whether other tools must drive it through an interface.
Cuttle: a browser on its own Chromium build
My own product, and the reason I can say the rest of this page without hedging. A browser built on its own Chromium build in C++ — not a wrapper and not a scripting layer over someone else’s app — with licensing, card and crypto payments, renewals and refunds. Releases are signed, and both signature and SHA-256 are checked before a file is replaced. There is a local API and webhooks, and it works with Selenium, Puppeteer and Playwright.
Cuttle is in early access by request. The point of the figures is the scope of the work, not a sales pitch for it.
See the caseQuestions people ask
Windows or macOS?
Either, or both. Which ones are worth doing depends on where your users are — and that goes into the quote, not into a guess.
Can you add licensing to an existing app?
Usually yes. After looking at the code I say honestly whether it is cheaper to add to it or to rebuild the part around it.
How do payments work?
Cards and cryptocurrency, with renewals and refunds handled. The money goes to your account, not through mine.
What about piracy?
Keys, activation and device limits raise the cost of copying; nothing makes it impossible. I say that plainly rather than sell a guarantee that does not exist.
Do you call?
No. I answer in writing, within one working day, in the channel you left.
Get a price for your desktop product
Describe the product and how it should be sold — the figure comes within two working days.
Get a price