Skip to content
LokumTech.

Custom business software

Custom internal software, built around the process you already have.

Order tracking, field forms, stock, approval flows, reporting. Laravel on the server, Nuxt in the browser, a private repository you own from the first commit — and a written scope with a fixed price before anything gets built.

Book a 30-minute callWhat it costs

Where this usually starts

Two stages, and both of them end here.

These are sentences from the first ten minutes of discovery calls. If you recognise three of them, you are not describing anything we have not seen.

The spreadsheet stage

  • One person spends two days a month assembling the report from four files.
  • The field team sends photos on WhatsApp and the office types the same information in again.
  • Two people opened the same file this morning and one version won.
  • The same customer exists three times, spelled three ways.
  • Nobody can say who changed the price on that order, or when.
  • The stock count and the system have not agreed for months.

The packaged-product stage

  • We bought the software. Our actual process is in a spreadsheet next to it.
  • The module we need exists, but it assumes a workflow nobody here uses.
  • Every small change becomes a change request with a queue in front of it.
  • The report the manager asks for every Monday cannot be built inside it.
  • It holds our data and we cannot get a usable export out of it.

What we build

Six shapes that cover most of what we are asked for.

Not industries — shapes. A joinery workshop's job tracking and a logistics firm's job tracking are the same software problem with different words on the buttons.

Order and job tracking

One record per order or job, moving through the states your business actually has, with who changed what and when. The thing a spreadsheet cannot give you is history.

Field forms and mobile capture

Forms that work on a phone in a van with two bars of signal: photos, signatures, offline entry that syncs when it can. The data gets typed once, by the person who has it.

Stock, warehouse and counts

Stock that moves when the paperwork moves, counts that reconcile, and a recorded reason behind every adjustment.

Approvals and permissions

Who may approve what, up to which amount, and what happens while they are on holiday. Roles, limits, delegation and an audit trail that survives an argument.

Reporting and dashboards

The report somebody currently rebuilds by hand every week, generated instead — with the numbers agreeing with each other, because they come from one place.

Integrations and data migration

Talking to the accounting system, the online store, the bank file, the marketplace API. Plus getting years of history out of the spreadsheets and into a schema that can be queried.

How a build runs

Five stages, and what you are holding at the end of each.

No proposal theatre, and no discovery phase that quietly turns into the project.

  1. 01

    Discovery and written scope

    Paid, timeboxed

    We sit with the people who do the work — not only the person who signs — and write the process down as it actually runs, including the exceptions everyone handles by hand. You get a scope with acceptance criteria, a fixed price and a delivery date. Stop here and the document is still yours; another studio can quote from it.

  2. 02

    Prototype

    2–3 weeks

    The core flow, clickable, with your real data in it. This is where "no, that is not how we do it" is cheap. Anything that surfaces here and changes the scope changes the quote in writing, before the expensive part starts.

  3. 03

    First release

    Fixed price, weekly demo

    The narrowest version that lets you stop using the spreadsheet: in production, on your server, with your history migrated and reconciled. We aim a first release at one process rather than the whole company, because that is what makes the date keepable.

  4. 04

    Handover and training

    Before the invoice closes

    Repository and account ownership are already yours; on top of that comes a runbook written for your situation rather than a generic manual — deployment steps, where the secrets live, what to watch, the known rough edges. Role-based training sessions, recorded, and a question window afterwards.

  5. 05

    Maintenance

    Monthly agreement or day rate

    The process changes, so the software changes. Dependency and security updates, small changes as they come up, and somebody who already knows the codebase at the moment something breaks. Or nobody: the handover is written so your own developer can take it.

If it is a product, not an internal tool

We run our own SaaS, so we know which parts get expensive.

Esimbit is ours: a multi-tenant SaaS where eSIM resellers sell under their own name, on their own provider and payment accounts — built here and operated here. When an order stalls between a reseller's payment and their provider, we are the ones who fix it. On your product it will be the same people.

  • Payments that fail: retries, partial captures, refunds, disputes, and the reconciliation afterwards
  • Fulfilment that fails: a provider timing out mid-order, with a customer who has already paid
  • A catalogue in more than one currency and more than one language, edited by people who are not developers
  • Support surfaces: an operator screen where somebody can see and fix one customer's order
  • Queues, retries, idempotency, and an error tracker somebody actually reads
  • Tenants, plans and limits: subscription billing, trials, and keeping one customer's data out of another's
  • Invoices, receipts, and the questions your accountant will ask in month three

What we are not: a growth or marketing partner, and not a co-founder for equity. We build the product and we can operate it with you; the market is yours.

See Esimbit

The stack behind both

Backend & data
LaravelPHPNode.jsPostgreSQLMySQLRedis
Frontend
NuxtVueTypeScriptTailwind CSSLivewire
Platform & delivery
AWSDockerGitHub ActionsCloudflareLinux

Ownership and exit

What is in the handover pack, itemised.

The two fears we hear most are the developer who vanished and the vendor you cannot leave. This is the answer to both, and it belongs in the contract rather than on a slide.

  • The repository in your own GitHub or GitLab account from the first commit — we are invited collaborators in it
  • Server, database and third-party service accounts opened in your name, on your payment method
  • An inventory of every secret and environment variable, and where each one lives
  • Deployment reduced to a documented command, run at least once by somebody on your side
  • The database schema, the migrations, and a backup and restore procedure that has been tested rather than just written
  • Automated tests covering the acceptance criteria we were paid against
  • A written list of known rough edges — we do not hand over a clean story and a dirty codebase
  • Recorded role-based training, and a question window after we step back

What it costs

Three ways this gets bought.

Starting prices are still being finalised, so what follows is the shape rather than the number. The number arrives in writing after the assessment, not as a range on a first call.

Discovery and fixed quote

Quoted after assessment

A timeboxed, paid piece of work that ends in a written scope, acceptance criteria and a fixed price. Credited against the build if you continue.

  • Process mapped with the people who run it
  • Scope with acceptance criteria
  • A fixed price and a delivery date
  • Yours to take elsewhere

Custom business software

Quoted after assessment

The build itself: fixed price against the scope discovery produced, invoiced against stages you can see running.

  • A weekly demo of something clickable
  • Your repository and accounts from day one
  • Data migrated and reconciled
  • Runbook, training and handover

Maintenance agreement

Quoted after assessment

Monthly, tiered by response time, with inclusions and exclusions both written down. Results, not hours logged.

  • Dependency and security updates
  • Small changes as the process changes
  • A stated response window
  • A monthly written summary

If the deciding factor is the lowest price, we are the wrong studio and we will say so on the first call. We are not competing with an hourly rate from a marketplace, and pretending otherwise costs you a month.

Invoiced by Lokum Tech LLC
Currency, VAT treatment and payment terms in the written quote
Two active builds at a time, so a start date is a real date

Starting prices for these packages are being finalised. Ask on a call and we will give you a number, not a range.

Pricing and engagement models

Cost, duration, ownership

The three questions everybody actually wants answered.

What does custom software actually cost?
It scales with the number of processes and the number of integrations, not with the number of screens. Discovery exists to turn that into one fixed figure, written down with what it buys and what it excludes. What we will not do is give you a range on a first call: a range wide enough to be honest is too wide to be useful, and a narrow one would be a guess.
How long does it take?
Discovery is timeboxed and its length is agreed before it starts. A prototype is two to three weeks. The first release gets a date in the written scope, and we deliberately aim it at one process so that the date is keepable. If we cannot say how long the next stage takes, we do not start it.
Who owns the code, the data and the accounts?
You do. The repository sits in your organisation from the first commit and we are collaborators in it. Server and service accounts are opened in your name on your payment method. There is no runtime licence payable to us, no key we hold back, and nothing that stops working if you stop paying us.
Is the fixed price really fixed? What happens when the scope changes?
The price is fixed against the written scope, and the scope will change — that is normal, not a failure. A change gets estimated first, then either replaces something of similar size or becomes a written addendum with its own price. What does not happen is silent extra work appearing on an invoice at the end.
Can it talk to the systems we already have?
Usually yes, and how easily depends entirely on what the other side offers. A documented API is a day; a nightly file export is a week; a system whose vendor will not let your data out is a conversation about that vendor. We check this during discovery, before it becomes a promise.
Would buying a packaged product be smarter for us?
Sometimes, and we say so. If your process is close enough to a standard one, a licence plus configuration beats a build on both cost and risk — we have told people exactly that. What tips it the other way is a process that is the reason your customers choose you. That is not something to bend to fit somebody else's screens.

Tell us the process that hurts.

Thirty minutes, no deck. We ask what happens today, who does it by hand, and what breaks when that person is on holiday — then we say whether this is work we should be doing.

Book a 30-minute callWho does the work