Rakkay Technologies

How we work

No surprises, in either direction.

Hiring a development team in another country is a leap of faith. This page is our attempt to make it a smaller one — the commitments we make, how a project runs, and what happens when something goes wrong.

What we commit to

Four things you can hold us to.

Each of these is a process rather than a promise — something with a repository, a document or a channel behind it, so you can check whether we are doing it rather than take our word for it.

  • You own the repository

    Code goes into your GitHub organisation from the first commit, not ours. You are never in a position where leaving us means losing the work.

  • Scope and cost agreed up front

    You get a written scope with the deliverables listed. Anything outside it is quoted separately before it is built, not invoiced afterwards.

  • You talk to the engineers

    No account manager relaying questions. You are in the same channel as the people writing the code, and you can ask them anything directly.

  • Documentation is a deliverable

    Setup, architecture decisions and deployment steps are written down as we go, so a new engineer — ours or yours — can pick the project up.

We don’t sell what we haven’t shipped.

Today that means React, React Native and the backends behind them. We’re building toward AI, machine learning and data science — and we’ll say so here when we’ve delivered that work for a client, not before.

The process

The first four weeks.

The opening month is the same on every engagement, whatever its size. By the end of it you have a scope you signed, a repository you own and an application you can open.
  1. 01

    Week 1

    Discovery and scope

    We work through what you are building and who it is for, then write the scope, the deliverables and the technical approach down for you to sign off.

  2. 02

    Week 2

    Architecture and setup

    Repository, CI pipeline, environments and data model. The skeleton the rest of the project is built on, in your GitHub organisation.

  3. 03

    Weeks 3–4

    First working build

    A running application you can open, not a design file. From here you see progress every week rather than at the end.

  4. 04

    Week 4

    Review and plan

    We demo what exists, agree what changes, and plan the next block of work against the scope.

After week four

Then it becomes a rhythm.

From week five the work settles into a short loop that repeats for as long as the engagement runs. You are never more than a few days from something you can open and judge for yourself.
010203Every weekFrom week five
  1. 01

    Build

    A short block of work against the scope you agreed, in your repository, reviewed by a second engineer before it merges.

  2. 02

    Demo

    A running application you can open yourself — not a screenshot, not a slide, not a percentage complete.

  3. 03

    Decide

    You say what matters most next. Priorities change; a plan that cannot absorb that is a plan that gets quietly ignored.

Architecture

Four things we decide before we write features.

On every project these are settled by a solution architect with 16 years in production systems, not by whoever picks up the first ticket. Deciding them late is the usual reason a project needs rewriting in its eighth month.

  • The data model

    What the entities are, how they relate, and what is allowed to be null. This is the most expensive thing to change later, because every screen and every endpoint ends up depending on it.

  • The API contract

    The routes, the shapes and the error cases, agreed before either side is built. Once a mobile app is in the store against an endpoint, that endpoint is close to permanent.

  • Where the state lives

    What is held on the server, what is cached, what is on the device and what happens when the device is offline. Getting this wrong is the usual reason an app feels slow no matter how much is optimised afterwards.

  • The riskiest part, named early

    Every project has one thing that could sink the timeline — a native SDK with poor documentation, a payment flow with an unusual settlement model, a migration off a live database. We identify it in week one and build a spike against it before it can surprise us in week ten.

Continuity

What happens if an engineer leaves mid-project?

This is the question most clients think about and few ask. It is a fair question to ask any small team, so here is the honest answer: we cannot promise nobody will ever leave. What we can do is make sure it is an inconvenience rather than a catastrophe.

  • The repository is yours from the first commit

    Code lives in your GitHub organisation, not ours. If we stopped working tomorrow you would still have every commit, every branch and every piece of history.

  • No engineer is the only one who understands your system

    Every project has a second engineer who reviews the code and can run the project locally. That review is what makes the knowledge transferable rather than a formality.

  • The documentation is written as we go

    Architecture decisions, environment setup and deployment steps live in the repository next to the code, updated in the same pull request that changes them. Documentation written at the end of a project is documentation nobody trusts.

Quality

How we keep the build from drifting.

None of this is unusual engineering practice. It is unusual to write it down for a client, which is the only reason it is on a page rather than in a handbook.

  • Nothing merges unreviewed

    Every change is read by a second engineer before it lands. CI runs on every pull request, so a build that does not compile, or a test that fails, never reaches a release branch.

  • Nothing ships you have not seen

    Before a release we work through the affected areas against the scope we agreed, and you get a build to try yourself while there is still time to change it.

  • Response times are contractual

    Bug-fix response times are agreed in your contract rather than promised on a web page, so there is something to hold us to.

  • Releases are automated, not heroic

    Build, sign and deploy run in the pipeline for web and for both app stores. A release that depends on one person remembering the steps is a release that eventually goes out wrong, at the worst possible time.

Start with a conversation.

Send us the problem, not a specification. We read every message ourselves and reply personally — and if we are not the right team for it, we will say so and usually point you to someone who is.

  • Read by an engineer
  • Answered personally
  • No sales sequence
Send a message