Skip to content

Services

I work with founders and teams who need software in production, not a prototype. The scope is always end to end: understanding the need, architecture, frontend and backend development, integrations, infrastructure and deployment.

Three offers cover the situations I meet most often. If yours sits between two of them, describe it and I will tell you what I would do first.

01

MVP & SaaS development

Build your MVP from idea to production.

You have a validated idea, or a product that needs to exist, and no technical team yet. I take it from requirements to a deployed, maintainable application that you own — frontend, backend, database, integrations and infrastructure.

I work directly with you, ship in usable increments and keep the scope honest: what gets built is what the first users need, structured so that the next features do not require a rewrite.

What's included

  • Discovery and scoping of the first release
  • Technical architecture and data model
  • Frontend (Next.js, React) and backend (NestJS, Node.js) development
  • Authentication, roles and permissions
  • Payment and third-party integrations (Mobile Money, email, messaging)
  • Database design (PostgreSQL, MongoDB)
  • Automated tests on the critical paths
  • Docker, CI/CD and deployment to production
  • Documentation and handover

Who it is for

  • Founders with a validated idea and no technical co-founder
  • Small companies replacing spreadsheets or manual processes with a real product
  • Teams that need a first version in production before hiring

02

Existing product engineering

Improve, stabilize and scale an existing product.

Your product is live but slows you down: recurring bugs, a fragile deployment, a feature nobody dares to touch, or an architecture that no longer fits. I join an existing codebase, understand it before changing it, and fix what hurts most first.

This is the work I have done for more than three years on Ekoh, a production SaaS for a South African company: new features, a full authentication rebuild, test coverage thresholds and a typed SDK — while the product kept running.

What's included

  • Codebase and infrastructure audit with a prioritized plan
  • Bug investigation and production incident fixes
  • Refactoring and architecture changes done incrementally
  • Test suites and coverage thresholds enforced in CI
  • Performance and security hardening
  • Authentication, authorization and session management
  • Deployment pipelines, Docker and monitoring
  • New feature development inside the existing product

Who it is for

  • Founders whose product is live but whose original developer has moved on
  • Teams that need a senior engineer for a difficult module
  • Companies whose technical debt is blocking the roadmap

03

Technical partnership

A technical partner before you need a full-time CTO.

Early-stage companies need technical decisions made well before they can justify a full-time CTO. I take that role on a recurring basis: architecture, priorities, delivery, and the technical side of conversations with partners, providers and future hires.

I hold this position on my own products, for a medical laboratory network whose platform I own end to end, and for Inter Solutions Service — an IT and travel company I partner with on Kuntriz. The commitment is continuity: I make the decisions, build alongside you, and stay accountable for what runs in production.

What's included

  • Technical roadmap aligned with business priorities
  • Architecture and build-versus-buy decisions
  • Hands-on development on the critical parts of the product
  • Code review and engineering standards for other developers
  • Provider and infrastructure choices (payments, hosting, tooling)
  • Hiring support and onboarding of your first engineers
  • Security, backups and production readiness
  • Regular reporting to founders and stakeholders

Who it is for

  • Founders who need a technical co-pilot without a full-time hire
  • Non-technical teams running a product built by an agency
  • Companies preparing to build an in-house engineering team

How I work

The same five steps on every engagement, whatever its size. The goal is a product that is usable early and stays maintainable.

  1. Step 01

    Understand

    I start by understanding the business problem, the users and what success actually means.

  2. Step 02

    Structure

    I turn the requirements into a clear technical approach and architecture.

  3. Step 03

    Build

    I build iteratively, keeping the product usable and testable throughout the process.

  4. Step 04

    Ship

    I take care of deployment, infrastructure and production readiness.

  5. Step 05

    Improve

    I use feedback and real-world data to continuously improve the product.

Questions I am often asked

Do you work remotely, and in which time zones?

Yes. I am based in Yaoundé, Cameroon (UTC+1), and I work remotely with clients in Africa, Europe and beyond. My hours overlap well with European time zones and most of Africa; for other regions I set fixed overlap windows for meetings and work asynchronously the rest of the time, with written updates.

How do we start?

With a call about your product, where it stands and what you need next. If we are a fit, I send a short written proposal: scope of the first phase, what you receive, timeline and price. Work starts once we agree on it.

How long does a project take?

It depends on the scope, so I do not promise dates before understanding the work. What I do is split the project into short phases, each ending with a working, deployable result, so you see progress early and can adjust the direction.

How do you price your work?

Per phase with a fixed scope when the work can be defined, or on a monthly retainer for ongoing engineering and technical partnership. Every proposal states exactly what is included. There are no figures on this site because they depend on the scope.

Who owns the code, and what happens at the end?

You do. The code lives in repositories you control from day one, with documentation, environment setup and deployment instructions. At the end of an engagement I hand over everything another engineer needs to continue, and I remain available for maintenance if you want.

Not sure which one fits?

Describe your situation and I will tell you what I would do first.