What a €420 starter review covers

When you have built an app and reached the edge of your technical confidence, buying help can be surprisingly difficult. A large development proposal may be premature. An automated scan may produce hundreds of warnings without explaining what matters. A free call can establish fit, but it cannot replace actually inspecting an application. A starter review creates a smaller, defined first engagement.

Launch a Tool’s Starter Review costs €420 plus applicable VAT and covers up to four total engineering hours for one app. That allocation includes assessment, a written findings report and a walkthrough. It is not four hours of code inspection followed by unlimited documentation and meetings. Fixes, deployment and hosting are separate work. We confirm suitability and timing before accepting the engagement.

Begin with the decision you need to make

A useful review starts with a decision, not a promise to inspect everything. You might need to know whether a small team can begin a controlled trial, whether an access-control concern deserves immediate attention, or what must change before moving from a builder’s hosted environment to your own infrastructure. Tell us what you intend to do next and what would make you hesitate.

The same app can require different work depending on its use. A demonstration with synthetic records is different from an application storing staff information or approving expenses. A tool used by the creator alone is different from one shared across customers. Understanding that context helps select the few flows that carry the most risk or business importance.

Before starting, we agree the app, the questions and the accessible materials. We may recommend narrowing the scope or commissioning a deeper assessment. That discussion is part of avoiding an engagement whose apparent simplicity hides unrealistic expectations.

What to prepare

Prepare a short description of the workflow, the expected users, the current deployment and your main concern. A public demo URL can help with the first conversation. Do not send passwords or private customer data through the public inquiry form. If an engagement proceeds, we agree an appropriate way to access code and a safe test environment.

Where possible, provide reproducible setup instructions and synthetic accounts for different roles. Explain which integrations can send real email, change external records or incur costs. A reviewer should not discover an active billing integration by accidentally invoking it. Read-only access is preferred for initial inspection; any additional access should have a specific purpose.

If the app cannot be run, record that limitation before the review. Static inspection can still identify useful issues, but it cannot demonstrate runtime behavior. Time spent resolving a broken setup consumes the same four-hour allocation as other engineering work. Agreeing the starting conditions prevents surprises.

How we choose what to inspect

We prioritize the agreed question and the most consequential paths. For a small internal app, this might include sign-in, one role boundary, the main write operation, an external integration and the deployment configuration. It is a sample chosen for relevance, not a statistical assurance that every similar path behaves correctly.

A review can examine whether secrets appear in client-delivered code, whether record ownership is enforced at the server, whether input is validated, and whether failures leave misleading success states. It may also identify unclear dependencies, fragile workflows or missing recovery instructions. Some findings are directly demonstrated; others are concerns that need a targeted follow-up test.

We keep those categories distinct. “A requester account retrieved another requester’s record in this test” is stronger evidence than “this authorization helper is difficult to follow.” Both may deserve attention, but they should not be presented as the same kind of finding. OWASP ASVS can guide relevant checks without implying complete coverage of its requirements.

What the report should let you do

The report should help you choose the next action. Each substantive finding needs enough context to explain the affected workflow, the evidence, the practical consequence, and a suggested response. A list of scanner output without interpretation is not an adequate handover.

Expect a concise overview of the scope, findings grouped by priority, questions that remain unresolved, and a recommendation for the next step. Include what was not tested. If only one user role was available or an integration could not be exercised safely, that limitation belongs beside the conclusion rather than hidden in a footnote.

Priorities should reflect the intended use. A record-access failure may block a shared trial. A confusing but recoverable validation message may be scheduled afterward. A naming inconsistency may make maintenance harder without posing an immediate launch risk. Distinguishing these helps you spend time and money in the right order.

The walkthrough is part of the work

The walkthrough connects findings to decisions. We explain the evidence, clarify terminology and discuss the next scope. You should leave knowing which issues need action before your planned use, which can wait, and which require more investigation.

The time-box means the walkthrough must stay focused. It does not include an indefinite series of follow-up meetings or open-ended debugging. Further work can be agreed separately. This protects the usefulness of a small engagement: both sides know what the first purchase contains.

You can use the findings to work on the tool yourself, discuss the changes with another engineer, or ask us to quote the next stage. The report is intended to improve your decisions, not to make continued work with one supplier the only option.

What four hours cannot establish

A starter review is not a penetration test, an exhaustive code audit, a compliance certification or a guarantee against future incidents. It does not establish that every dependency is safe, every integration behaves correctly or every possible permission path has been tested. It does not include fixing all discovered issues or migrating the application into production.

Large codebases, multiple applications, complex payments, highly sensitive data or poorly documented infrastructure may require a different scope. These are reasons to discuss the work before accepting it. A transparent boundary is more useful than a broad promise that cannot be supported by the available time.

Likewise, a recommendation to proceed with a limited trial is specific to that trial. Adding new user roles, integrations or data categories can change the risk. A review is a dated assessment of a particular state, not a permanent label attached to the app.

Choosing the next engagement

At the end, there are several reasonable outcomes. The next step may be a small set of fixes, a deeper investigation, a controlled launch, or a decision to pause. A rewrite should be justified by the findings, not assumed because the original code was generated with AI.

For follow-on work, ask for a separate scope with deliverables, assumptions, responsibilities and cost. Hosting costs and maintenance commitments should be visible rather than silently bundled into “launch.” Keep the distinction between one-time engineering and recurring operations clear.

If you are not sure whether the Starter Review fits, begin with the free 30-minute fit call. Explain what you have and the decision you need to make. The first useful result is agreement on the right problem to inspect.

Sources and scope

• OWASP Application Security Verification Standard — a reference for technical requirements, not a claim that this package covers the complete standard.
• Example starter-review report — an illustrative deliverable, not a customer audit or evidence of measured client outcomes.