Software that holds up in production.

• Build & launch

  A prototype or inherited codebase that has to go live

  It works in a demo, but security, payments, deployment and ownership are not ready for paying customers, or for a team to take over.

  Startup Builder →

• Run & scale

  Production that is slow, fragile or hard to scale

  Incidents repeat, latency climbs, or a migration, backup or capacity decision rests on guesswork — across Kubernetes, cloud, databases and observability.

  Run & Scale →

  Also: TiDB Performance Sprint · Scale Sprint

• Integrate & automate

  Work held together by hand

  The same information is re-keyed between e-mail, spreadsheets, APIs and internal systems, and the process depends on someone remembering.

  Integrations & automation →

None of this is only an engineering cost. It is latency a customer notices, a launch that waits on work nobody has scoped, or hours spent every week on a process a system could carry. Not sure which fits? See every service.

• Employment

  Database and site reliability engineering

  Database Reliability Engineer at Bolt, 2022 – October 2026: distributed SQL reliability at scale, with Prometheus and Grafana observability. Before that, SRE and then SRE Team Lead at Entigo. Employment, not MoiToi clients, partners or endorsements.

• Background

  Production infrastructure since 1995

  Linux, databases, distributed systems and observability — operated, not only designed.

• MoiToi client work

  Zoovet — a commerce platform modernised without stopping the business

  Long-term stewardship of a B2B veterinary wholesaler’s Django/Oscar platform and the servers around it, migrated incrementally while it keeps taking orders. Client since 1998.

  zoovet.dev →

• Own product · live pilot

  MerVare — marina booking, payments and a sensor bridge

  Designed, built and operated by Andres: a booking state machine, Stripe Connect payments to the harbour and a hardware bridge built to report berth occupancy. Owned, not client work.

  Case study →

Code and open-source work: github.com/kepsic. No client logos, results or endorsements are shown without the client’s permission.

1. Step 1

   Describe the problem

   A 30-minute call about what is slow, fragile or not yet launch-ready, and why it matters. It decides honestly whether there is work worth doing.

2. Step 2

   Evidence before changes

   Where the cause is not yet clear, a bounded, paid review or audit establishes it before anything is built or changed.

3. Step 3

   An agreed sprint

   Scope, baseline and acceptance checks are agreed before work starts. The work is hands-on, in your code, databases and infrastructure.

4. Step 4

   Measured handover

   The result is checked against what was agreed and handed over documented, so your team can own it without depending on MoiToi.

Defined engagements, each with its own scope: TiDB Performance Sprint · Production Readiness Audit · Scale Sprint · All services

• TiDB Engineering

  Before a MySQL to TiDB cutover, let TiDB run your production queries first

• TiDB Engineering

  A TiDB backup nobody has restored is an assumption, not a recovery plan

• Startup Builder

  How do I make an AI-built prototype production-ready?

• Case study · own product

  Mervare: from a phone call on VHF to an operating system for small harbours.

All articles →TiDB guides →