Skip to content
Solutions

The right solution is not always more software.

Five practices, from understanding how the business works today to building and running the answer. Most engagements use more than one, and some end with a process change and nothing installed at all.

Where to start

Choose your starting point.

If none of the five practices is obviously yours, pick the sentence that describes your situation instead.

Engagements

How an engagement starts.

Five named pieces of work rather than a price list. Most clients begin at the first or the second, and each one is useful on its own even if nothing follows it.

  1. Problem
  2. Assessment or discovery
  3. Process improvement or solution blueprint
  4. Build and deliver
  5. Continuous improvement

Most engagements start at the left. Each step is useful on its own, and stopping after any of them is a normal outcome.

01One-time

Business & Technology Assessment

Diagnose.

You know something is wrong and you are not yet sure what, or which part to fix first.

What you get

  • Current-state assessment
  • Process observations
  • Systems inventory
  • Pain-point register
  • Opportunity map
  • Quick wins
  • Prioritized roadmap

Book a Business & Technology Assessment

02Per engagement

Process Improvement Sprint

Redesign one important workflow.

You already know which process is the problem and want it fixed rather than surveyed.

What you get

  • The workflow mapped as it actually runs
  • Diagnosis: where it stalls and why
  • A redesigned future state agreed with the people who run it
  • Business rules written down
  • What to automate, and what deliberately stays manual

Improve a Process

03Per engagement

Solution Blueprint

Turn an idea or a problem into a build-ready definition.

You want something built and need it defined properly before anyone writes code — including if that someone is not Arohan.

What you get

  • Problem statement
  • Personas
  • Journeys
  • Requirements
  • Business rules
  • Integrations
  • Roles and permissions
  • MVP definition
  • Architecture concept
  • Roadmap

Discuss a Software Idea

04Per engagement

Build & Deliver

Take the approved solution into production.

The definition exists and is agreed. Now it has to be built, tested, deployed and adopted.

What you get

  • The application, integration or automation itself
  • Tested against the agreed rules
  • Deployed, with the environment and configuration documented
  • UAT, handover and adoption support

Discuss What You Want to Build

05Ongoing

Arohan Technology Partner

Ongoing product, technology, process and delivery support.

You need the capability available continuously rather than assembled for each project.

What you get

  • Standing product and technology support
  • Continuous process improvement
  • Delivery capacity when a piece of work needs it
  • One person accountable across the whole picture

Start a Conversation

Arohan prices on outcome, complexity, responsibility, risk and scope rather than on hours alone.

Nothing is charged before a scope is written down and agreed, with what is included, what is not, and what it costs. If a project is not a fit, that gets said early rather than quoted at.

Questions

Asked before every first conversation.

How much does a project cost?

It depends on the outcome, the complexity, and how much responsibility Arohan is carrying — not on a rate card. An assessment and a built application are different questions. You get a written scope with the number in it before anything is agreed, and nothing is charged before that.

How long does it take?

It depends entirely on scope, so an honest answer now is worth less than a date in writing later. The scope you agree to includes the timeline, and it is set once the work is actually understood rather than guessed at in a first email.

Do I have to know what I want built?

No, and most people do not. That is what the assessment is for. You can start with a description of what is going wrong; working out whether the answer is a process change, an integration, an application or nothing at all is the job.

Do I have to take a whole engagement?

No. Plenty of work is one piece: a process mapped, a technology decision reviewed, a workflow automated. The practices sit together because one person can carry all of them when a project turns out to need more than it started as, which happens more often than not.

What if the answer is that I do not need software?

Then that is the answer, and it gets said early rather than quoted at. Automating a broken process makes it fail faster, and a system built around a workflow nobody wants is an expensive way to keep it. Fixing the process and installing nothing is a legitimate result.

Who actually does the work?

Harsh does. There is no team to hand you to and no account manager between you and the person building the thing. That is the point of the arrangement, and it is also why scope gets agreed carefully rather than optimistically.

How quickly will I hear back?

Within two hours, in practice, and it will be Harsh rather than an autoresponder. If something is urgent, the phone number on the contact page works.

Not sure which of these you need?

That is the normal starting position, and working out which of these it actually is happens in the first conversation rather than before it.