MAKIN 
Services taught us what repeats.
After enough engagements the shape recurs: the same booking flow, the same stock sync, the same approval chain with a different logo. Productising is not abandoning services — it is refusing to rebuild the same foundation at a client’s expense for the fourth time.
What we productised and what we did not.
The parts that are genuinely identical across clients became products: auth, payments, catalogue, scheduling. The parts that encode how a particular business actually operates stayed bespoke. Getting that line wrong in either direction is expensive — too much product and it fits nobody, too little and you are an agency with extra steps.
It changes what clients pay for.
A client buying a product pays for a thing that already works and a short adaptation. A client buying a service pays for time. The first is cheaper and faster when the fit is good, and a poor trade when it is not — so we say which one applies before the proposal, not after.
The hard part is support, not build.
Shipping a product is a quarter of the work. Versioning it, supporting several clients on different releases, and deciding whose request becomes a feature — that is the actual business, and it is the part services work does not prepare you for.
A fit test you can run before any call
You can answer a good part of the product-or-service question yourself, before anyone quotes. Write down the workflow the software has to carry, in the order your staff actually do it, and hold it against the product’s feature list or demo. You are not looking for a perfect match, only for whether the mismatches sit at the edges of your process or in the middle of it.
- Mark each step the product handles as it stands, each it handles with configuration, and each it does not handle at all.
- Circle the steps a customer would notice. A gap there matters more than a gap in a back-office screen.
- Write down the rules that are yours alone: pricing exceptions, approval limits, how you split an order.
- If the gaps cluster in the middle, you are looking at a service. If they sit at the edges, a product with a short adaptation is usually the better trade.
Buy, rent or build on top
Once a product fits, the next decision is how you hold it. Buying outright is a one-time payment for the source code and a perpetual, non-exclusive licence to host, extend and run the software for your own business. Renting is a monthly licence: you run the product and keep what it earns, with a smaller commitment up front.
The trade-off is control against commitment. If the software sits close to how you compete, having the source code matters, because you will want to change it on your own schedule. If you are still testing whether a market exists, renting keeps the first step small. White-label and customisation are offered too, and the same question of control against commitment applies to each.
Where the product ends and your business begins
The same line between identical and business-specific parts should decide how an adaptation is built. Your changes belong outside the product’s core wherever possible: your pricing rules, approval chains and integrations sit in their own layer and talk to the product through defined points. That separation is what allows improvements to the product to keep flowing through to you without overwriting the work that makes the software yours.
When you evaluate any productised offer, ask where customisations live. If the answer is that the vendor edits the core separately for each client, every update becomes a merge, and within a few releases you are running a private version that nobody else maintains. That is the agency with extra steps, arrived at slowly and paid for twice.
What a seven-day launch asks of you
Products on the site launch in seven days: you pick the product and the model, it is branded as yours, we deploy and test it, and you launch with training and an admin handover. The calendar can be that short because the software already exists. Your part of that week is supplying inputs, so have these ready before the first day.
- Logo files, brand colours, typography preferences and the domain you intend to use.
- Final copy and content: product or service names, prices, policies and the words on the home screen.
- A payment gateway account in your business’s name, since Razorpay or Stripe is wired in during deployment.
- Store developer accounts in your company’s name if the product ships as a mobile app.
- One person who can approve decisions the same day, and the staff who will attend the training.
Questions to ask any product vendor, us included
Support is easy to overlook before signing, yet it decides whether a product is still useful a few releases later, so ask about life after launch, not only the launch itself. Our ready-made products page shows each product with its buy and rent prices, and lists what comes with them: full source code on every buy, brand customisation, deployment and hosting setup, an admin panel, payments where the product takes them, documentation and training, three months of support and product updates. The questions below apply to them as much as to any other vendor.
- Who decides which requests become features, and how will you hear the decision on yours?
- How are updates delivered, and can you hold one back until you have tested it?
- What does support cover after launch, and what happens when the included period ends?
- If you bought the code, how do later product improvements reach your copy?
- If you rent, how does your data come out, and in what format, when you stop?
When a service is still the right call
Productising does not mean steering every enquiry toward a product. If the workflow you need is the reason customers choose you, if the software has to sit between several systems unique to your setup, or if your rules change faster than a shared product could follow, a service is the honest recommendation. So is the case where a product covers most of what you need but the missing part is the part that matters.
A close fit that leaves the hard problem unsolved is a poor trade, however quickly it launches. Services and products both carry published starting prices on our pricing page, so you can compare the two routes before the call. For a service, your fixed price arrives in writing after the scope call.