THE WEBDROP APPROACH
Less theatre.
More thoughtful engineering.
Useful software starts with a specific job and the people who need it done. We intend to keep the scope clear, test the essentials and improve what earns its place.
This is the approach we plan to apply as the products develop. It is not a claim that unreleased software has completed testing, an independent audit or customer validation. Product release, paid sales and wider promotion remain separate decisions.
01 / FROM PROBLEM TO PRODUCT
Four stages.
Evidence at each step.
Each stage should produce a concrete result or a clear reason to stop. A calendar deadline is not a substitute for a useful, safe workflow.
01 / Understand
Find the actual job.
Ask for a recent example, who does the work and what happens when it goes wrong. Examine the current workaround, maintained plugins and native platform features. If an existing option solves the same task well, there should be a meaningful reason to build another one.
02 / Build
Keep the scope useful.
Choose a small, complete workflow and write down its boundaries. Build the ordinary journey with clear setup, understandable states and a useful result. Keep product behaviour separate from the company website, and avoid adding adjacent features merely to make the catalogue look larger.
03 / Test
Prove the important parts.
Check the intended outcome and the ways it can fail. Use synthetic records first, then suitable staging environments with permission. Record the version, setup, expected result and actual result. A passing demonstration should not be treated as evidence for an untested environment.
04 / Improve
Listen to real use.
Use observed setup difficulties, support work and independent customer experience to decide what changes next. Distinguish a useful suggestion from a repeated problem. A larger release should follow evidence that the product is valuable and can be maintained, rather than the desire to announce more features.
02 / FREE WITH A PURPOSE
Correctness belongs
in the basic product.
A free edition should finish a real task. A paid edition should justify its place by reducing recurring work, with a clear boundary that customers can understand.
FREE / THE INTENTION
A whole useful workflow.
The basic outcome should include understandable setup, useful defaults, essential diagnostics and honest limits. It should not depend on a trial countdown or paying to correct a wrong result. If manual operation meets a small business's needs, remaining on Free should be a sensible choice.
PRO / THE INTENTION
Work worth automating.
Paid capabilities should address repeated administration or operation that customers can identify and value. They need their own demonstration and evidence. A badge, a larger feature count or interest in the free core does not establish demand for a paid workflow.
03 / CHECK THE ORDINARY AND THE FAILURE
Useful when it works.
Clear when it cannot.
Testing should cover the whole relevant journey. A clean screenshot or an automated check alone cannot establish correctness, accessibility or privacy.
The expected result
For Upgrade, the test plan includes eligibility, current prices, rounding, tax presentation, checkout, payment, downloads and refunds. For a Connect package, it would include mapping, preview and the website result. Supported platform versions and compatibility should be published only after the relevant cases have actually been tested.
The difficult result
Test changed data, unavailable services, empty results, duplicate events and a safe recovery route. Check keyboard use, visible focus, narrow screens and reduced motion. Keep credentials and private customer information out of public pages and diagnostics. Privacy and security-sensitive decisions need review appropriate to their risk.
04 / EVIDENCE BEFORE EXPANSION
A release needs more
than finished code.
Internal use can reveal a problem. Independent use is needed to learn whether other suitable customers can get the same useful result.
Ready to operate
Before a release, the intended checks include a reproducible artefact, clear requirements, installation guidance, known limits and a recovery plan. Download and support routes need to work. Paid selling also needs tested purchase and refund arrangements, including any licence renewal or cancellation process offered, with the actual terms explained before a customer commits.
Independent products
Upgrade and Connect should develop on their own evidence. Progress on one does not prove the other is ready. We would expand a product when the need, paid value and maintenance work support that decision. At present, Upgrade remains in development and Connect remains in research. Enquiries, downloads and sales are closed.
THE FIRST PRODUCT DIRECTIONS
See the job.
Check the scope.
Explore what Upgrade and Connect are intended to do, who they may fit and where each product stands.