Build vs. buy
Test before you build.
Before funding a larger software build, test the idea on a small scale. An established business can run that test with the customers and staff it already has. The first question is not which features to build — it is what you most need to learn, and the cheapest honest way to learn it.
Test a new service or workflow on a small scale before funding a larger software build. An established business has an advantage here: you can test with existing customers or staff, who already trust you enough to try something rough.
The point of a pilot is to learn, not to ship. Start from the question — will customers use this, can we deliver it, does the information change a decision? — and pick the cheapest test that answers it honestly.
The useful test is not whether you can build the full thing. It is whether a small, real trial gives you enough evidence to expand, change direction, or stop.
Five ideas, five small tests.
These are illustrative experiments, not evidence that the ideas will succeed.
In each case the test is manual and narrow — enough to produce real evidence, cheap enough to abandon.
Learn by hand before you automate.
For a distributor weighing a reorder portal, the progression can be deliberately low-tech.
Processing orders by hand reveals the exceptions — the odd pricing, the special delivery, the half-finished request — before they become expensive software requirements. One honesty rule: be clear about what the pilot actually provides. Do not present a service you are confirming manually as instant automation.
Match the evidence to the decision.
Most software projects fail on one of three risks: technical feasibility — can you build it, and reach the data and integrations it needs? customer demand — does the problem matter enough that people will actually use it? and business viability — will they pay enough to cover the cost of delivering it? Name the risk your idea is most exposed to, and test that one first.
Different questions need different tests. Reach for the lightest one that answers yours:
- Interviews reveal the real problem and the workarounds people use today.
- A landing page tests whether there is initial interest at all.
- A concept video shows the idea in action and tests whether the promise alone pulls interest, before anything is built.
- A clickable prototype tests whether people understand the flow and can use it.
- A technical trial tests whether an existing system can actually share the data you need, before you design a workflow around it.
- A live pilot tests actual use, delivery effort, and whether it fits how you operate.
- Payment and repeat use are the strongest evidence that the value continues beyond novelty.
None of this is new or exotic. Dropbox tested demand with a demo video before building the product, Airbnb started by renting out the founders' own apartment, and Zappos ran a concierge service — filling its first orders by buying shoes from local shops by hand — to see whether people would actually pay, not just sign up. Each answered one risky question cheaply before anyone committed to the full build.
Before starting, set a limited scope, a budget, a review point, and success criteria. For customer-facing services, measure completion, repeat use, support effort, and willingness to pay; for an internal tool, lower effort and fewer errors matter more than enthusiasm — compare time, errors, and adoption against the current process.
Guard against flattering evidence. Include people beyond your most enthusiastic customers, and look into why others decline or abandon the test — that is usually where the real objection hides. A generic sign-up percentage is not a universal pass mark; judge the result against the decision actually in front of you.
Fund the learning, not the whole build.
Match the funding to what you are testing. An internal efficiency project needs an operating case: what it costs, what it improves, and when the benefit appears. A new customer-facing product needs that plus evidence that customers will actually pay. Turning your own process into a product to sell to other businesses needs more again — evidence that the problem, and the willingness to adopt a solution, exist beyond the company that thought of it. Outside investment raises a separate question about ownership and growth expectations, and a funding platform cannot establish that a project is worth building; it should not stand in for any of these tests, and a successful campaign still leaves delivery and operating costs to manage.
If you do look outward, "a funding platform" means several very different things. Reward crowdfunding lets you pre-sell a product and keep full ownership, but commits you to delivering it. Equity crowdfunding brings in investors who receive shares, with the disclosure rules, eligibility limits, and dilution that implies. Other platforms are less a place to raise money than tooling to find, manage, or report to investors. Their fees, obligations, and ownership implications differ sharply, and the market changes often — so compare current terms directly, and remember none of them is evidence that the demand is real.
So fund the learning first, in stages:
- Set a spending limit for learning. Include setup, staff time, migration, training, and support — not just the tool.
- Spend it on the most uncertain assumption. Will customers order through the portal? Will staff keep the production records current?
- Use the smallest workable solution. A configured tool or a manual pilot often gives enough evidence before any custom development.
- Release the next budget against results. Define success before the pilot starts, and compare it against the current process.
- Check the continuing cost. Subscriptions, maintenance, integrations, and the work still done by hand all outlast the build — and decide whether the benefit covers them.
Small, but still dependable.
A pilot can be narrow, but it still handles real orders, records, and commitments — so reduce the scope without cutting the parts users need to complete the task or trust the result. "Rough" should describe the edges, not the handling of someone's actual order.
Treat the evidence as early, not final. A small pilot shows what happens with a few users; it does not establish how the solution behaves across every customer, a busy period, or an unusual case. Let expansion test those remaining uncertainties rather than assume the pilot already settled them.
For CYBERCUBE, the useful starting point is the single question you most need answered before committing. Run the smallest credible test, measure what it tells you, and use that to decide whether to expand, change direction, or stop. Tell us what you're thinking of building. If the pilot proves it out, see how to scope a dependable first application; if you're still weighing it, when custom software makes sense covers the decision.