okeep.tech

We build it with you, as your technical side.

You know the business, the customers, and the price they will actually pay. Everything technical is ours — the architecture, the code, the servers, the releases, and the phone that rings at 2am. We do not hand over a repository and disappear.

Start with a conversation

One lead engineer reads it. Reply inside one working day.

Two panels side by side. The left, already filled in, is the customer's: three of their own clients with amounts, two paid and one waiting. The right is ours: deployed, migrations applied, monitoring on call. Both feed down into a third panel labelled "your product", which fills with the same clients and a revenue line, and goes live.

Stays yours

The half we will never pretend to know better than you.

  • The customersWho they are, what they will tolerate, why they leave.
  • The priceWhat the market pays, and what a discount really costs you.
  • The decisionsYou own the roadmap. We argue, then we build what you chose.

Becomes ours

The half that quietly sinks projects when nobody owns it.

  • Architecture and codeWritten to be changed next year, not just to pass a demo.
  • Infrastructure and releasesShips by tag; a failed migration cancels the deploy before anyone notices.
  • Monitoring and the 2am callWe find out before your customer does, and we answer it.
  • LaunchAnalytics, adverts, the sign-up nobody abandons. Software nobody uses is not finished.

How it goes

01

We argue about scope

Before any estimate. Most requests contain one thing that matters and four that were assumed. We find which is which, out loud.

A conversation, then a written scope

02

Smallest thing that is real

Not a prototype nobody can use. The narrowest version a real customer can pay for, running on real infrastructure.

Weeks, not quarters

03

Launch is part of the build

Analytics wired, the sign-up tested by strangers, the first advert paid for and measured. Otherwise you own software nobody found.

Before we call it done

04

We stay

Same engineer, same system, next month and the month after. What broke, what to build next, what to switch off.

For as long as it is useful

A technical side, not a supplier.

A supplier quotes a scope, delivers it, and is gone before the first real user arrives. That is exactly when the real questions start: what broke, what to build next, why the advert stopped paying for itself.

We stay on our side of the table after launch, because that is where the work that matters happens. You get one engineer who knows your system, not a rotating queue of tickets.

Ways to work together

  • Scope it

    You have an idea and no plan

    We take the idea apart, name what is actually being bought, and write the scope, the architecture and the risks down.

    A written plan you could hand to anyone — including someone else.

  • Build it

    You have a plan and no team

    We build and launch it: product, infrastructure, releases, analytics, and the first customers who pay for it.

    A running product, and the keys to all of it.

  • Be our side of it

    You have a product and no technical side

    Ongoing: features, incidents, upgrades, the 2am call. One engineer who knows your system, not a ticket queue.

    Nothing — that is the point. We do not leave.

What people ask before saying yes

Who actually owns the code?

You do, from the first commit, in your own repository and your own accounts. We work inside your infrastructure, not on top of a platform you have to keep renting from us. If you ever want to move on, nothing has to be extracted or bought back.

You are small. What happens if you disappear?

A fair question, and the reason everything is written down: the scope, the architecture decisions, the reasons behind them, and the runbook. The honest test of that documentation is whether another engineer could take over without calling us. We also run four of our own products on the same stack, so it is not a side project we can quietly abandon.

Can you take over something already built?

Often, yes. We start with a read-only week: run it, read it, find what is actually broken versus what is merely unfamiliar, and tell you honestly whether it should be continued or replaced. Sometimes the answer is that it is fine and you need less than you thought.

How do you charge?

Fixed price for scoping, because that work has a defined end. Monthly for building and for staying, because pretending a living product has a final invoice is how both sides end up unhappy. No lock-in period; the work stops the month you say stop.

We already do this on our own money

Not a portfolio of things we handed over. Four products we own, run and pay for — the same platform, the same team, the same 2am phone.

okeep.auto car workshops · okeep.resto restaurants ·okeep.analytics marketing · okeep.voice telephony

Four product names — auto, resto, analytics, voice — each wired down into a single box labelled okeep.tech, holding one account, one design system and one release pipeline: one team behind all four.

Tell us what you are building

Plain words are fine: what the business does, what keeps getting in the way, and what you wish existed by this time next year. You do not need a spec — working out what is actually worth building is the first thing we do together. One lead engineer reads this and answers within a working day, including "not yet, and here is why".

Or write straight to hello@okeep.io