HOW IT WORKS

Start with the bottleneck. Then fix what matters.

A straightforward process that makes responsibilities, outputs and next decisions visible before work begins.

Six-stage workflow: diagnose, recommend, define scope, build or refine, verify, and hand over.

Diagnose → recommend → define scope → build or refine → verify → hand over. The detailed stages below also explain the agreed post-launch check; this is not an ongoing maintenance commitment.

Open full-size visual ↗Open mobile version ↗
  1. 01

    DIAGNOSTIC

    Understand the current position.

    What happens
    Arunaksha reviews the business, current website where available, public information, customer questions and paths to enquiry.
    What I need from you
    Accurate business details, the current website if one exists, and a clear description of the problem you are trying to solve.
    What you receive
    Practical observations and a recommended direction—not an automated platform score.
    What happens next
    Decide whether there is a meaningful project and which service path fits.
  2. 02

    SCOPE & RECOMMENDATION

    Choose the appropriate level of work.

    What happens
    The required pages or improvements, exclusions, responsibilities and commercial boundaries are defined before work begins.
    What I need from you
    Questions, constraints, relevant access requirements and confirmation that the proposed direction matches the business need.
    What you receive
    A defined recommendation and scope for an upgrade, a new foundation or no rebuild where one is not justified.
    What happens next
    Agree the scope, inputs, review method and handover terms before implementation.
  3. 03

    BUILD / IMPROVEMENT

    Make the agreed changes.

    What happens
    The approved structure, content, contact routes and technical essentials are implemented within the defined scope.
    What I need from you
    Accurate copy inputs, approved assets, access where agreed, timely decisions and consolidated feedback.
    What you receive
    The agreed website foundation or focused visibility improvements ready for verification.
    What happens next
    Review the implementation through the agreed revision process and prepare for launch.
  4. 04

    LAUNCH & VERIFICATION

    Check the foundation.

    What happens
    Routes, contact points, mobile usability, metadata and agreed launch items are checked before the work is treated as ready.
    What I need from you
    Final factual approval and any owner-controlled domain, hosting or account action agreed in the scope.
    What you receive
    A launch-checked implementation and a record of anything intentionally deferred or owned by another provider.
    What happens next
    Publish through the agreed production arrangement, then allow the site to operate before the post-launch review.
  5. 05

    POST-LAUNCH CHECK

    Review what is working.

    What happens
    One agreed 30-day post-launch check reviews the implementation and any visible issues within the original scope.
    What I need from you
    Relevant observations, enquiries or access to agreed evidence where available.
    What you receive
    A focused review of the launch foundation and any sensible next action; not an ongoing maintenance or SEO retainer.
    What happens next
    Act only on useful evidence. Any new work is separately scoped rather than assumed.

WEBSITES AND BUSINESS SYSTEMS

The process starts the same. The work does not.

Start by choosing whether the problem is public discovery, an online internal workflow, or a task on one Windows computer.

Business Web Apps & Backends

For a browser-based dashboard, user login, database, portal or custom online workflow connected to a public site when required.

Explore Web Apps & Backends →

Private Desktop Software

For a tailored offline-first application running on one primary Windows workstation, quoted separately.

Explore Offline Software →

ADDITIONAL STEPS FOR SOFTWARE

Business systems need more than a website launch checklist.

For custom web applications, discovery maps users, permissions, data structure, integrations, hosting, privacy and operations before any estimate. A written proposal includes acceptance cases, security controls, backup/restore expectations, deployment, handover and support responsibilities.

For offline Windows projects, requirements instead focus on one workstation, installation, local persistence and recovery. A thirty-day website check is not automatically a software warranty or maintenance contract.

See the web app scope → · See desktop software →

START WITH CLARITY

Get a clearer view of what needs fixing first.

Describe the customer journey or repeated task you want to improve. We will work out the appropriate scope together.

Discuss the problem