AlvankraTechnologies

What we build

Applications, and the discipline to keep them alive.

Internal tools, customer portals, workflow systems, integrations between things that were never meant to talk. Web and mobile.

01 — The work

Four stages, in detail.

01

Design

We start by writing down what the software has to do, who touches it, what data it holds, and what it must never lose. Then we draw the screens. You approve a plan you can actually read before anyone writes code, because changing a diagram costs an afternoon and changing a database costs a fortnight.

You get: a written scope, screen flows, and a fixed price for the build.

02

Build

Working software, in front of you, every week. Not a percentage on a status report — a link you can click and use. That cadence exists because the useful feedback always arrives when someone touches the real thing, and the earlier that happens the cheaper it is to act on.

You get: a weekly build to try, and a running list of what changed.

03

Deploy

Into your accounts, under your billing, with monitoring so failures announce themselves rather than being discovered by a customer. Everything is documented — how it's built, where it runs, how to restore it. If we vanished, another developer could pick it up.

You get: production access, runbooks, and the keys in your name.

04

Maintain

Dependencies age, security patches land, browsers change under you, and the business asks for things nobody imagined at the start. Ongoing work is scheduled and visible — you always know what's queued and what it costs.

You get: patched dependencies, scheduled improvements, and a roadmap you control.

02 — How we engage

Three ways to work together.

Most sites hide this until they've got you on a call. Knowing roughly what things cost should not require a meeting.

A

Discovery

A short, paid piece of work that ends in a written scope, a design, and a fixed price. If you then take that document to someone else to build, it's yours and that's a legitimate outcome.

B

Fixed-scope build

A defined application for an agreed price, delivered in weekly increments. Best when the problem is well understood — usually after discovery.

C

Ongoing retainer

A set number of days per month for maintenance and improvements, once something is live. Cancellable. It should never feel like a fee for being allowed to keep your own software.

Not sure which? Almost everyone starts with discovery. It's the cheapest way to find out whether the thing you want is the thing you need — and occasionally it ends with us telling you that off-the-shelf software already does this and you should buy that instead.

03 — Ownership

Who owns what, in plain terms.

You own what we build for you

The application, its code, its data, and the accounts it runs in. In your name, in your repositories, from day one — not handed over at the end if the relationship stays friendly.

We keep our own tools

The internal libraries and scaffolding we bring to every project stay ours, and you get a permanent licence to use them. That's what stops you paying us to rebuild the same foundations from scratch.

Leaving is always possible

Documented, credentialled, and handover-ready throughout. We'd rather you stayed because the work is good than because the exit is painful.

Tell us what you're trying to build.

A sentence about the problem beats a formal brief. If we're not the right fit we'll say so, and point you somewhere better.