How We Work
A plain-language walkthrough of the RANA process, from first conversation to ongoing delivery.
We're experts. That's why you're here.
RANA is not a general-purpose agency that takes random requests and figures it out. We are a contracted development agency that works against specific, defined requirements and we ship them. Reliably, on time, at the cost we agreed on.
When requirements are clear and the process is followed, we give you a date and we hit it. When the process breaks down, things get unpredictable for everyone. This document exists so that does not happen.
We will always tell you what is possible, how long it will take, and what it will cost. Our job is to make great software. Your job is to know what you want to build and give us clear direction to build it. We are good at ours. This process helps you be good at yours.
You bring the problem and the scope. We bring the plan.
Scoping is 1 to 2 focused conversations. The client comes in with a clear picture of what they want to build. RANA listens, asks the right questions, and then independently produces the timeline and cost estimate. You leave with a real document in hand.
What the client brings
- / The core problem they are solving and the user it is for
- / The rough scope of what they want built: features, functions, and any known constraints
- / Honesty about budget, timeline pressure, and what is still unknown
What RANA produces
At the end of scoping, RANA independently assesses the work and produces the High Level Document. This is our deliverable and it goes to the client before anything else is signed.
The High Level Document (HLD)
The HLD is what RANA produces after scoping conversations are complete. It is our independent assessment of the project and it serves as the foundation for everything that follows. The client always leaves scoping with this document in hand.
The technical approach and architecture: how we plan to build it, what the stack looks like, and any infrastructure considerations.
Our independently determined timeline for the project, based on the scope the client brought. This is RANA's assessment, not a negotiation.
The cost quote, derived from the timeline. For example: 3 months at $96,000 per month. This number is ours and we stand by it. It does not change unless scope changes.
We always propose at our full rate. That said, we ask clients to be open with us about budget early. If there is a gap, we would rather have that conversation honestly at the start than have it become a problem later. See the Pricing section for how we handle that.
Before prototyping starts, we put the agreement in writing.
Once the client has reviewed the HLD and both sides are aligned, we sign a Statement of Work. This is the initial contract between RANA and the client.
What it covers
- / Our commitment to the timeline and cost from the HLD
- / The scope as understood at the start of the engagement
- / The terms that govern the relationship going forward
The Statement of Work is signed before prototyping begins. The HLD and the Statement of Work together set the foundation. The prototype and the Scope of Work that follows it are what make the requirements fully concrete.
We prototype before we build. Every time.
If there is any frontend to your product, any user interface at all, RANA builds a prototype before a single line of production code is written. This is non-negotiable, even if you come to us with existing designs or mockups.
Why we do this
The prototype is primarily a tool for keeping scope honest. It makes the agreed requirements tangible so you can see exactly what was defined and confirm it matches your vision before we commit to building it. This is how we protect the timeline and cost we quoted in the HLD.
- / Prototypes make the agreed scope visible and concrete before dev begins
- / They surface misalignments early, when changes are cheap
- / They give both sides a shared, unambiguous reference to sign off on
- / They ensure no one is surprised by what gets built
Scope only increases if the client wants it to. If you want to add features or functions beyond what was scoped, we welcome that conversation. We will tell you clearly what the addition means for the timeline and cost. You decide. The original quote holds for the original scope.
If scope increases during prototyping, the estimate increases with it. We flag this proactively every time. Our job during prototyping is to keep you in scope so the HLD numbers hold. Adding scope is always your call, not ours.
How prototype iteration works
We share prototype versions, you review and respond, we refine. This continues until the prototype fully represents what you want to build. There is no set number of rounds. We iterate until you are satisfied and ready to sign off.
Prototype approved? Now we lock in what gets built.
Once you have fully approved the prototype, we produce a Scope of Work document. This is a separate and more specific document from the Statement of Work signed at the start.
Statement of Work
The initial contract. Sets the cost commitment, timeline, and terms. Grounded in the HLD produced at the end of scoping.
Scope of Work
Defines exactly what will be built. Anchored to two sources of truth:
The HLD — the technical approach and architecture produced at the end of scoping
The approved prototype — which defines the features and functions to be built
Two hard rules
- / No development begins before the Scope of Work is signed
- / No prototype iterations happen after the Scope of Work is signed
The Scope of Work is the handshake. It marks the clean line between figuring it out together and building what we agreed on.
Clear ownership on both sides.
Once the build begins, both RANA and the client have specific, non-overlapping responsibilities. Keeping these clear is what keeps the project moving.
We own the build, the team, and the outcome.
- / Deliver on the agreed scope, timeline, and cost
- / Manage the full team: leads, specialists, QA, design, and PM
- / Proactively flag scope changes and their implications
- / Surface decisions that need client input
- / Ship working software that matches the signed prototype
You own direction, feedback, and decisions.
- / Know your app's full scope; do not discover core requirements mid-build
- / Respond to review requests within 24 to 48 hours
- / Give specific written feedback on design vibe, style, colors, logos, and edits
- / Make decisions clearly and promptly when asked
- / Avoid adding scope without understanding the timeline impact
On design feedback specifically
When we share design work, your feedback needs to be specific. "I don't like the vibe" is a start. "The button color feels too aggressive and the logo treatment on the header needs more breathing room" is what we can act on. Vague feedback produces slow iteration. Specific feedback produces fast results.
We commit to a cost and a deadline. Both.
Once the Scope of Work is signed, we build. RANA commits to delivering on time and on budget. If we do not, you do not pay extra.
Roughly 1 in 3 projects ship ahead of the committed deadline.
Roughly 1 in 3 projects ship exactly when we said they would.
Roughly 1 in 3 run long. You still pay only what was agreed.
This same commitment applies to every sprint after the initial build, not just the first delivery.
typical range for full products
maintenance or full dev months
When you hire RANA, you hire RANA.
Not a developer named Robert. Not a designer named Steve. RANA. Our commitment is to the outcome, not to any individual, and that is a feature, not a limitation.
A full team you never have to manage.
Every project has lead developers and a management layer. Behind them is a vetted bench of specialists we pull in when the work demands it. You interact with none of them directly. You work with RANA.
No developer is ever permanently assigned to a project. We keep lead continuity where we can, but our system is built so any developer on our roster can step in at any time without disrupting delivery. The project never depends on a single person. If we do not have the skill a project needs, we will tell you. But that is rare, and when it happens, we say so before we take the work.
Clients do not talk to developers. Clients do not request specific team members. Clients do not manage RANA's resources. You tell us what you want to build. We tell you how we will get it done. Then we get it done. That clarity is what makes us fast.
Great partnerships work both ways.
We move fast and hold ourselves to a high standard. We ask that clients meet a clear, reasonable bar in return.
24 to 48 hours
On designs, prototypes, and shared app versions. Written form, even rough notes are fine.
Written, always
Not because we are formal, but because written feedback is clearer, more actionable, and harder to misinterpret.
Expectation of fullness
When we share something for review, a design file, a prototype, or a live app version, we ask that you give it real time and real thought. Go through it fully. Make a list. Think, rethink, add to it. Send feedback that represents your complete thinking at that moment.
This matters because once you send feedback and we build to it, revisiting earlier decisions becomes expensive. "Expectation of fullness" is our term for the habit of sending thorough, considered responses the first time, on everything from visual direction and color to flows and feature behavior.
After launch: the 40-point system.
Once the initial build is complete, ongoing work is planned and prioritized using RANA's point system.
How it works
- / Each sprint draws from a pool of 40 points
- / Every feature or task is sized using Fibonacci numbers
- / You decide what gets done and in what order; we advise on sizing and tradeoffs
- / What fits in 40 points ships. What does not waits for the next sprint.
- / Any month with 30 or more points of work is billed as a full month at the full rate
Fibonacci sizing reflects how development actually works: small tasks are predictable, large ones carry uncertainty. Bigger point values mean bigger complexity, not just more hours.
The 40-point system keeps scope honest and keeps sprints realistic. It is a shared language for deciding what matters most right now, and it keeps us working the way we work best: against defined requirements with a clear commitment on the other end.
Straightforward rates. Room to talk.
RANA's full rate is $96,000 per month. We always propose at that rate. What happens after that depends on the conversation.
we are stage-aware. We want to make it work.
We started RANA because building apps should not be as hard as it is. That means we are genuinely open to finding a structure that works for where a client is today, with the goal of getting to a healthy long-term relationship.
We are always open to multiple ways of making an engagement work. If you are transparent with us about where you are, we will be transparent with you about what is possible.
The RANA process, condensed.
- / We are experts hired to build specific things: requirements in, working software out
- / Client brings the problem and scope; RANA independently produces the timeline, cost, and HLD
- / The HLD goes to the client at the end of scoping, before anything is signed
- / Statement of Work signed before prototyping begins
- / Prototype built before any dev work starts, always
- / Prototyping keeps the client in scope; scope only grows if the client wants it to
- / Scope of Work signed after prototype approval, anchored to the HLD and the approved prototype
- / Fixed cost and timeline commitment; overruns are on us
- / When you hire RANA, you hire RANA, not individual developers
- / Lead devs, specialist bench, QA team, and management layer, all managed internally
- / Founder is responsible for knowing full app scope; client is responsible for specific, written feedback
- / 24 to 48 hour written feedback expected at every review stage
- / Post-launch: monthly sprints sized with the 40-point Fibonacci system; 30 or more points is a full month
- / Full rate is $96k per month; maintenance is 10% of contract rate; stage-aware pricing and equity available for the right fit
This document is intended for prospective and active RANA clients. For questions, reach us at nate@ranadev.io.