Dorian Laroche Faleu Β· Web & Mobile Developer Β· Buea, Cameroon

I build products
that hold up in production.

Third-year student at the University of Buea and developer at Cestad Consulting. Four projects I designed are running online today. Two were delivered to a German client: a marketplace that collects payments and issues compliant invoices, and an exam platform for a German technical certification. The other two are my own products: a multi-tenant SaaS platform that web agencies resell under their own brand, and a mobile commerce solution open to eighty-three countries.

Projects in production
4
Delivered in Germany
2
Automated tests
327
Countries served
83

Client project Β· Germany

Studenten-Jobportal

A two-sided marketplace built for a German client: individuals and companies post a job, students apply, the platform collects the payment, takes its commission and pays out. Full design and development, from the database schema to going live. Live at studenten-jobportal.de.

  • Next.js 15
  • React 19
  • TypeScript
  • Supabase
  • Stripe Connect
  • PostgreSQL
Studenten-Jobportal home page

The site is live: studenten-jobportal.de

The problem

A student looking for a few paid hours and a household that needs help moving have a hard time finding each other. Classified ads guarantee neither payment, nor identity, nor recourse in a dispute. Both sides take a risk that neither can afford to carry.

What I built

Guided job posting

A five-step funnel calculates the cost in real time, category by category, and saves a draft at every step. An "Other" entry in each family lets clients describe a need the catalog didn't anticipate.

Escrow payments

Stripe Connect with destination charges: the client pays upfront, and the money is only released to the student after validation. Webhooks are idempotent β€” a replayed event never triggers a second payout.

Masked contact details

Email addresses, phone numbers and links stay hidden in the messaging system until the booking is confirmed. Without this, both parties bypass the platform and nobody is covered anymore.

Compliant invoicing

PDF invoices generated in memory with the mandatory Β§ 14 UStG mentions: 19% VAT, service date, continuous numbering. No external binary, so no hosting provider is ruled out.

Identity verification

ID document and proof of enrollment uploaded to a private area and reviewed by hand. Students must provide a profile photo: whoever enters someone's home shows their face.

Full admin panel

Fifteen screens: moderation, assignment, refunds, disputes, blog publishing, audit log. Every sensitive action requires a written reason and leaves a trace.

Three technical decisions

Three authorization layers, not one

The middleware filters routes, server guards check every action, and PostgreSQL RLS policies replay the same rules inside the database. A flaw in one layer is not enough: the database refuses what the code would have let through.

State machines, not booleans

Jobs, applications and bookings follow declared, tested transitions. The UI only shows a button if the transition is allowed β€” it never offers what the server would refuse.

Money as integers

Amounts are stored in cents, rates in per mille. No float ever touches a euro: a 12.5% commission is written 125, and the recalculated total always gives the same result.

Quality

169unit tests β€” pricing, permissions, transitions, invoices
29end-to-end tests, full client ↔ student journey
298pages generated at build time, zero errors
0TypeScript errors, strict mode

German market constraints

The target market imposes its own rules, and ignoring them is expensive. The site respects the current minimum wage, displays an Impressum compliant with Β§ 5 DDG, applies the right of withdrawal, anticipates platform tax reporting (PStTG) and hosts its data in Frankfurt β€” no transfer outside the European Union to document.

Client project Β· Germany

TGA-Planung

A learning platform for German building-technology professionals. At its core is an exam simulator built to the DIN 14675 standard, which governs fire alarm and voice alarm systems β€” a field where certification is a condition for practicing. Live at tga-elektrotechnik.de.

  • Next.js
  • React

The problem

Preparing for a DIN 14675 certification happens with binders and paper questionnaires. Candidates revise without ever knowing where they stand: they discover their gaps on exam day, when it is too late. And the existing material is scattered across standards, manufacturer manuals and internal company documents.

What I built

Timed exam simulation

Seventy questions, ninety minutes β€” the real conditions of the exam. The timer is part of the exercise: revising without time pressure does not prepare you for the exam you will actually sit.

No sign-up required

Candidates start a simulation immediately, without creating an account. Every registration form placed before the value drives visitors away β€” and creates obligations around data nothing forces you to collect.

Instant scoring

The result comes at the end of the series, question by question. A test whose correction you never see teaches nothing; it is the explanation of the answer that makes you progress.

Two separate tracks

Electrical engineering and HVAC have their own paths. A technician preparing a certification should not have to wade through a neighboring trade's material to find their own.

Knowledge base and articles

A reference section and technical articles accompany the simulations. It is also what makes the site findable: practitioners search for precise answers, not a brochure page.

Integrated shop

A shop section with a cart completes the platform, built on the same foundation as the rest of the site β€” not a bolted-on external store, so one visual identity and no second tool to maintain.

German compliance

The site provides an Impressum and a privacy statement, both reachable from the footer β€” the two pages any commercial site aimed at the German market must make available.

Product Β· Multi-tenant SaaS platform

LeadKlar

A platform that web agencies resell under their own brand: each agency opens a workspace per end client, fills it with that client's information, and drops a tag on the client's website. The assistant answers visitors from that validated information only, qualifies them, collects their contact details with consent, and hands over to a human as soon as it has no validated answer. Full design and development. Live at www.leadklar.com.

  • Next.js 16
  • React 19
  • TypeScript
  • Supabase
  • PostgreSQL RLS
  • Stripe
  • Resend

The problem

A web agency knows how to sell a website, not how to build conversational infrastructure. And the generic assistants on the market have a flaw its clients cannot accept: they make things up. An approximate price or an invented financing condition binds the business displaying the assistant β€” not the vendor who supplied it.

What I built

Refusal to invent

The assistant only answers from validated fragments, which it cites. Without a source, it says so and offers an advisor instead of an approximation. Verified in production: asked about a financing option missing from its base, it refuses to confirm it.

Strict tenant isolation

Agencies and client workspaces are isolated by RLS policies enforced in the database itself. An agency requesting another agency's workspace gets a 404, not an empty page: the resource's very existence is not revealed.

Embeddable widget

A single tag to paste. The script is 5 KB, dependency-free, and only opens the iframe on first click. Allowed origins are declared per workspace: a tag copied onto another site does not render.

Consent before collection

No contact detail is stored without the visitor's explicit, timestamped consent. IP address fingerprints are truncated then hashed: enough to limit abuse, not enough to re-identify a person.

Billing and entitlements

Stripe subscriptions with signed webhooks, workspace quotas per tier, and manual account opening for deals settled by bank transfer. A failed payment closes access without deleting data.

Operations

Timestamped audit log, per-workspace processing cost tracking with a daily cap, signed outbound webhooks with a delivery log, automatic retry of failures.

Three technical decisions

The answer is schema-constrained, not parsed after the fact

The output is not free text to be analyzed later: it is constrained to a JSON schema on the server. The confidence level, the cited fragments and the human handoff request are typed fields, not sentences to interpret.

The widget lives in an iframe served from my domain

The host site's CSS cannot reach it, and its calls stay same-origin. Display permission is carried by the frame-ancestors header, computed per request from the origins declared for that workspace.

Cost is measured on every answer

Tokens consumed, latency and estimated cost are recorded message by message. A daily cap per workspace cuts spending before a high-traffic site lets it run away β€” pricing does not depend on the visitor's goodwill.

Verified

404returned on another agency's workspace, zero leakage
0disclosure under prompt injection, tested in production
14API routes, including two scheduled jobs
5 KBthe script embedded on the end client's site

Product Β· Mobile commerce, 83 countries

BAOBAY

A platform where a merchant opens an online store in thirty minutes, from their phone: they upload products, share a link, and receive orders on WhatsApp. Every store carries its owner's logo, color and name β€” not the platform's. Full design and development, from the data model to going live. Live at baobay.org.

  • FastAPI
  • Python 3.13
  • SQLAlchemy 2
  • PostgreSQL
  • Jinja2
  • Framework-free CSS
  • Pillow
  • Campay

The problem

In Cameroon, commerce happens on WhatsApp. The seller posts product photos, the customer asks for each price one by one, sends the order as free text, and the seller copies everything by hand. Existing solutions cost as much as a custom website β€” out of reach for someone selling clothes or meals.

What I built

A storefront that is truly theirs

The merchant picks one color; every shade is derived from it with verified contrast, down to the browser bar tint. Their name is the tab title, their logo the favicon. The platform only appears in the footer.

Pricing by country

The subscription follows the market's purchasing power, not an exchange rate: 5,000 FCFA in Cameroon, 1,000 shillings in Kenya, €14.90 in France. A single converted price would be unaffordable here and trivial elsewhere.

The country's own payment methods

Seventy-two payment methods, offered in local order of use: M-Pesa first in Kenya, Pix in Brazil, UPI in India. Offering "Visa" first in Nairobi would be as absurd as offering M-Pesa in Paris.

Live preview during creation

While the merchant fills in the form, a mockup of their storefront builds itself alongside: name, address, logo and color apply live, computed by the server β€” never by a second formula that could diverge.

Images processed on arrival

Server-side reduction at the single entry point of every upload: 1.8 MB becomes 247 KB. EXIF orientation is applied, and the GPS coordinates phones embed in photos are stripped before publication.

Order alerts

A sound, a banner and a counter on the tab title β€” what a merchant who lives on WhatsApp actually sees. Push notifications would require a verified business; this is the best possible alert with zero paperwork.

Three technical decisions

Amounts in each currency's minor unit

Every amount is an integer in its currency's smallest unit: cents for the euro, francs for the FCFA, which has no subdivision. This rule made it possible to open up to sixty-one currencies without rewriting a single line of existing data β€” the FCFA having no decimals, the amounts already stored stayed exact.

A reference catalog instead of columns

Payment methods used to be five booleans β€” MTN, Orange, Airtel, card, delivery. They became text codes backed by a catalog of eighty-three countries. Adding M-Pesa no longer requires a database migration, and converting the old columns happens store by store, without a mass rewrite.

Deletion is logical, never physical

A deleted store disappears from the public site and the sitemap, but its orders and payments stay in the database. Erasing them would strip the merchant of their records in a dispute and break references to money already collected and accounted for.

Quality

129tests, green on every release
83countries, 61 currencies, 72 payment methods
85%less weight on stored images
0client-side JavaScript dependencies

What the field imposed

The product targeted a market where data is expensive and the phone is the only computer. Photos are therefore reduced in the browser before upload, and again on the server so nothing slips through. The interface stays usable on a 320-pixel screen, and payments can be collected by hand until the registration required by payment aggregators is obtained β€” a local regulatory constraint that drives the timeline far more than the technology does.

Skills

What I know how to do

Frontend

  • React 19, Next.js 15 (App Router, Server Components)
  • Strict TypeScript
  • Tailwind CSS, Radix UI
  • Accessibility: keyboard navigation, ARIA, contrast
  • Responsive, from 320 px mobile to large screens

Backend

  • Server Actions, Zod validation
  • PostgreSQL, Row Level Security
  • Supabase (database, auth, storage)
  • HMAC-SHA256 signed sessions
  • Rate limiting, audit logging

Integrations

  • Stripe Connect, signed and idempotent webhooks
  • Resend β€” transactional email, SPF, DKIM, DMARC
  • PDF generation (pdf-lib)
  • Geocoding, radius search

Conversational assistants

  • JSON schema-constrained outputs
  • Answers grounded in cited sources
  • Human handoff instead of approximation
  • Prompt injection resistance
  • Per-answer cost tracking, spending caps

Method

  • Vitest, Playwright
  • Git, continuous deployment
  • Technical SEO: sitemap, structured data, local pages
  • GDPR: right to erasure, data minimization, consent

About

Who I am

I am a third-year student at the University of Buea, Cameroon, and I work as a web and mobile developer at Cestad Consulting. I design and build applications end to end: the database schema, the business logic, the interface, the tests, then the launch.

What interests me in a project is not stacking screens, but making the rules hold: a payment that goes out exactly once, an authorization the database refuses even if the code gets it wrong, an invoice that stays compliant when the law requires it.

I work remotely, for European and African clients alike. I am open to freelance engagements and long-term collaborations.

What I deliver

The three products presented above were carried out solo, from data modeling to going live: schema and security policies, business logic, interface, tests, continuous deployment, domain name and transactional email. In every case, these are systems that handle money or personal data β€” the kind of code where a mistake shows.

See my services and pricing β†’

Contact

Let's talk

A question about a project, a proposal, a collaboration: write to me, I answer within one business day.