Skip to content
Berlin · availableAI Product Engineer

I ship finished products, not prototypes.

Fullstack product engineer in Berlin. Four systems in production, built in four months alongside a full-time job: apps in both stores, a multi-tenant SaaS with statutory fiscal signing, an autonomous agent. All of it mine, from the migrations to the legal notice.

See the work
For recruiters
systems in production
0
commits in 4 months
0
API routes (MenuCloud)
0
test cases
0
Selected work

Four products. All live. All built alone.

No practice projects, no tutorial clones. Every system here has real users, real payments or real legal obligations, and I owned each one from the first line to the store review.

01

Salati

Live in both stores2026

Prayer and Quran platform for German speakers, with AI that runs offline

Sole developer · product, code, stores, licensing

Salati's Quran reader on Android TV: the Arabic verse set large, transliteration and German translation below, remote-control hints at the bottom.
Android TV · Leanback
Salati's AI answering a question from Quran and hadith on a phone, explicitly marked as AI-assisted and naming the source of the answer.

The problem

Existing prayer apps are ad-funded, track aggressively, and treat the Quran reader as an afterthought. Anyone wanting to study in German (tafsir, translation, transliteration, isolated and connected letters) finds nothing coherent. And all of it breaks the moment the network drops.

The solution

An ad-free platform across five device classes: iOS, Android, Android TV, Wear OS and an HDMI stick for mosques. Prayer times are computed locally, the full reader with multiple reciters and translations works offline, and the question-answering model runs quantised on the device. No query ever leaves the phone.

The hard part

Speech recognition for Quranic recitation

The memorisation mode has to hear whether a verse was recited correctly. The obvious route, a larger Whisper model, was the wrong one. The leverage was in the method: condition the model on the expected verse as a prompt, normalise Persian and Urdu letter variants before comparing, and score leniently rather than as pass or fail. A base model fine-tuned on Tarteel now beats one three times its size, at a fraction of the on-device latency.

  • Five device classes from one monorepo: phone, tablet, Android TV, Wear OS, HDMI stick
  • On-device LLM (GGUF via llama.cpp) with custom RAG over a curated corpus, no cloud call
  • Whisper-based recitation checking with verse-conditioned prompting
  • Complete Mushaf reader: four typefaces, tafsir, translation, word-level timestamps
  • A 15-part German Quranic-Arabic podcast, produced through a two-voice ElevenLabs pipeline
  • Over-the-air updates via EAS: content corrections without a store cycle
  • iOS Live Activities and Android widgets for the next prayer time
  • App and store copy maintained in 14 languages, across four device classes
  • AI answers cite their source and carry an EU AI Act Art. 50 disclosure
device classes
0
languages
0
AI runs on the device
0 %
commits
0
salati.proInstagram
02

MenuCloud Berlin

Live in production2025–2026

Multi-tenant SaaS for restaurants, including statutory fiscal signing

Founder & sole developer

menucloud-berlin.de
Home page of menucloud-berlin.de promising zero commission, GDPR and cash-register compliance, with a preview of the self-service admin.
A restaurant page in the MenuCloud app on iPhone: menu, reservation, opening hours and description of a Berlin restaurant.

The problem

Berlin restaurants hand 15–30 % commission to delivery platforms and have no control over their own menu. The alternatives are website builders with no till integration, or enterprise systems with four-figure setup fees. Neither solves the problem every German restaurateur actually has: compliance with the cash-register law.

The solution

A platform covering the whole path: a restaurant site with a self-editable menu, QR ordering that pays out directly through Stripe Connect, reservations, reputation management. Underneath sits a multi-tenant cloud signing unit that signs every transaction under § 146a AO and anchors it in a hash chain. Plus native apps for owners and staff.

The hard part

Fiscal signing as a tenancy problem

A signing unit is not simply an API call. Each tenant needs its own legally attributable unit, every transaction must sit in an unbroken hash chain, and an outage must never quietly produce unsigned revenue, which for the restaurateur would be an audit catastrophe. The answer is a per-tenant provisioned Fiskaly cloud unit with the chain persisted in tse_transactions, and a fail-closed path: no signature, no transaction.

  • 1,276 API routes across 812 versioned Postgres migrations
  • Multi-tenant architecture with row level security per restaurant
  • Stripe Connect destination charges: restaurants are paid directly, the platform fee is settled automatically
  • § 146a AO compliance: per-tenant Fiskaly cloud signing unit, hash chain persisted
  • 5,340 test cases (5,163 unit, 177 end-to-end), the end-to-end suite running against production
  • Menu scanner: a PDF or a photo goes in, a structured menu comes out
  • Self-hosted mail stack with a three-stage fallback chain
  • GDPR Art. 30 record, data-processing agreement dispatched automatically on payment
  • iOS and Android apps for owners and service staff
API routes
0
DB migrations
0
test cases
0
hosting & data residency
EU
menucloud-berlin.deStatus pageInstagramYouTube
03

WohnungsJäger

In personal use2026

An autonomous agent that reads the Berlin rental market faster than a human can

Sole developer

There is deliberately no image of this project. The dashboard shows real listings, real addresses and my complete application documents. Staging a screenshot with invented data would have been the obvious fix, and would have put a fabricated image on a page that argues from verifiability. The architecture beside it is real.

The problem

A Berlin flat draws applicants in the hundreds. What decides it is not the best application but the first, within minutes of the listing going up. That is a race a human structurally cannot win, because humans sleep.

The solution

A locally running agent that scans five portals around the clock, checks each new listing against defined criteria, sends borderline cases to an LLM for a full-text assessment, and drafts an individual cover letter. It ships in REVIEW mode: it sends nothing without approval, until you deliberately switch it to automatic.

The hard part

An agent that does not act unasked

What makes such a system appealing is also its risk: a bot sending applications with your real personal data can do real damage. So the shipped state is REVIEW: propose, do not send. Automatic mode exists, but as a deliberate user decision rather than the default. The same logic sits in the watchdogs on my other projects: self-healing always with a cooldown, a cap, and a visible alert on every intervention.

  • Playwright with persistent Chrome profiles per portal: real sessions instead of brittle scrapers
  • LLM full-text assessment with a rule-based fallback when no key is configured
  • Local SQLite storage; the server binds to 127.0.0.1 by default
  • REVIEW mode as the shipped state: nothing is sent without human approval
  • Watchdog with automatic restart after a crash
  • Multi-instance operation for parallel accounts, distributable package without personal data
portals watched
0
scanning
0/7
review stages before sending
0
04

NOURI

Beta2026

Fitness and nutrition platform with a web app, a mobile app and its own API

Sole developer

nouri-fitness.vercel.app
Home page of the NOURI platform showing the recipe catalogue, weekly planning and training section.

The problem

Nutrition apps are either trackers without planning or planners without real data. And almost all of them treat errors as cosmetics: when the server is unreachable they display “saved” and lose the entry.

The solution

A platform of web app, Expo app and Fastify API sharing a catalogue of nearly 12,000 recipes, with macro tracking, weekly planning, shopping lists, pantry management and training plans. And with an API that separates three states cleanly instead of obscuring them.

The hard part

Reporting failure honestly

Every write endpoint distinguishes explicitly: secrets missing (dry run, no pretence that data was saved), database unreachable (503), database reachable but rejecting (a real 4xx carrying the Postgres error code). It sounds like a detail, but it is the difference between a system you can believe while debugging and one that lies to you.

  • Monorepo with a shared catalogue across web, mobile and API
  • 59 tables across 12 versioned migrations, row level security active
  • Supabase auth with cross-device profile sync
  • Using the app without an account stays entirely local, no forced login
  • Explicit failure states instead of silent 500s
recipes in the catalogue
0
tables
0
migrations
0
nouri-fitness.vercel.app
Who I am

Four years learning. Four months shipping.

I taught myself software engineering from 2022: first through structured courses from Meta and Udemy, then through my own projects. No computer science degree, no bootcamp. In 2026 it turned serious: four production systems in four months, two of them shipping in both app stores, one carrying statutory fiscal signing, all of it built alongside a full-time job.

What I learned doing it now governs how I work: a green test run proves nothing. I had an Android widget where every test passed and which rendered empty on a real device. And I spent months believing my update delivery worked, because the tool reported “Published” after every release. Not a single user ever received anything.

Since then the same rule sits in every one of my repositories: “should work now” is not a result. Every change is verified against the live system: by HTTP response, database query, or a screenshot from a real device. That is why I can ship fast with AI agents without quality becoming a claim.

commits in 4 monthsalongside a full-time job
0
systems in productionall built alone
0
app storesiOS and Android, live
0
self-taught sinceMeta & Udemy certificates
0

All figures were measured on 1 August 2026 using git rev-list HEAD --count across the three monorepos behind Salati, MenuCloud and NOURI. Only the main branch is counted; across all refs it would be 4,162. Commit counts keep growing, so any deviation is upward, not downward.

Path

  1. since 04/2026

    Founder & product engineer

    MenuCloud, sole proprietorship, Berlin

    Building and running four production systems as the only developer: product, architecture, delivery, operations and compliance in one pair of hands.

  2. since 2022

    Software engineering, self-taught

    Meta (Coursera) · Udemy · own projects

    No CS degree, no bootcamp. The evidence is four systems in production and a git history anyone can check.

Certificates

Every entry opens the issuer's verification page. All ten also kept as PDFs

Open source

My production systems stay private, they carry customer data and licensed content. What is published is what could be lifted out of them: the tools built along the way, and the rules that followed from the mistakes.

How I work

AI is a tool, not an excuse

I have worked agent-assisted for over a year. It compresses delivery from months to days, but only because there is a system around the agents that catches their mistakes. Without it, AI-assisted development is a machine for producing plausible-looking rubbish.

  1. 01

    Context as versioned code

    Every project carries its conventions as a file in the repository: import rules, test patterns, design tokens, security defaults. Plus a memory that persists across sessions: every lesson becomes an entry with its reasoning, not a note in a chat log that is gone tomorrow. An agent is only as good as the context it reliably finds.

    • A conventions file per repo
    • Persistent memory
    • Append-only project log
  2. 02

    Parallel work instead of waiting

    Long runs such as builds, test suites and store uploads go to the background while I keep working. Independent research goes to specialised sub-agents with their own context window. The bottleneck in agent-assisted development is rarely the model; it is the serialised way of working in front of it.

    • Sub-agents
    • Background tasks
    • Turborepo caching
  3. 03

    Verification instead of trust

    “Should work now” is not a result. Every claim about system state needs evidence: an HTTP response, a database query, a Playwright screenshot, a received email, an actual cron execution. This rule has repeatedly surfaced bugs in my own projects that had slipped through green test suites, because the tests were checking the wrong thing.

    • Playwright against production
    • Screenshot diffs
    • Live database checks
  4. 04

    Recurring fixes become automation

    When I do the same thing a third time, it becomes a workflow. Cron-aware watchdogs monitor services, heal known failures themselves, and report to Slack. Always with guardrails: a cooldown, a cap, an alert on every intervention. A watchdog that repairs blindly does more damage than it prevents.

    • 46 n8n workflows
    • Self-healing with a cap
    • Slack ops alerts
  5. 05

    Compliance as definition of done

    Every customer-facing feature passes the same gate: is there a lawful basis under GDPR? Does outreach respect German unfair-competition law? EU AI Act Art. 50: is the AI labelled as such? Does the site promise anything we do not deliver? For consumer products in the EU that is not an extra; it is part of the product.

    • GDPR Art. 30
    • Automated processing agreements
    • AI Act disclosure
agent-session

A real bug, re-enacted: A replay, not a live session. Cause, file and change are in commit bce08f5e.

Delivery pace

The difference is not that I type faster.

It is that research, implementation, testing and verification run in parallel rather than in sequence, and that context does not get lost between sessions. What that produces can be counted.

daysfirst commit on 16 April 2026 until today
107
versions shipped1.0.0 to 1.45.0, listed in the app's own changelog
63
per version on average107 days divided by 63 versions
40 h

Figures for Salati, counted on 1 August 2026 in the app's changelog file. Three further systems were in production alongside it.

Capabilities

Broad enough for the whole product, deep enough for the hard parts.

There are no percentages here. Nobody can check whether someone knows TypeScript to 93 per cent, so next to each capability stands the system it came from.

Frontend & product

Interfaces that work as well on a five-year-old Android as on a studio display.

React / Next.js App Router
Next.js 16 RSC in production
React Native / Expo
Expo SDK 57, RN 0.86, five device types
TypeScript
Strict everywhere, 0 errors as a merge gate
Motion & interaction
Reanimated 4, Framer Motion
Core Web Vitals
LCP/CLS/INP budgets in CI
Accessibility
TV focus navigation, reduced motion

Backend & data

Multi-tenant systems with real money, real tax law and real consequences when they fail.

Postgres / Supabase
59-table schema, RLS, migrations
API design
Fastify, route handlers, Zod validation
Payments
Stripe Connect destination charges
Multi-tenancy
RLS plus per-tenant provisioning
Mail infrastructure
Self-hosted stack with a fallback chain
Compliance systems
§ 146a AO signing, GDPR Art. 30

Cloud, delivery & operations

I run what I build, including the night shift when something falls over.

Vercel / edge
Static exports, rewrites, ISR
Docker / Coolify / Hetzner
Own VPS stack in production
CI/CD
GitHub Actions, Turborepo, EAS Build
Store delivery
App Store & Play, including OTA updates
Observability
Sentry, Uptime Kuma, Slack alerts
Automation
46 n8n workflows, self-healing

AI integration

From the agent pipeline in my editor to the quantised model on the user's phone.

Agent orchestration
Sub-agents, tool pipelines, loops
On-device inference
llama.cpp/GGUF, whisper.rn
RAG & retrieval
Own corpus, granularity measured
Prompt engineering
Verse conditioning beats model size
Evaluation
Local iteration against the same GGUF
AI regulation (EU AI Act)
Art. 50 disclosure as a gate
Writing

Five bugs that taught me something

Out of my own systems, with cause, fix and commit. No recycled tutorials.

Read all five articles
For recruiters & CTOs

The essentials in 60 seconds

No cover letter needed. Here is what I can do, what I am looking for, and how to reach me.

I ship finished, not nearly finished

Four systems in production, including store reviews, payment processing, GDPR documentation and legal notices. The part most portfolios leave out is exactly the part that takes longest.

I work across the whole stack

React Native widget, Postgres migration, Docker Compose on my own VPS, fiscal compliance. No ticket ping-pong because something is “not my area”.

Evidence over gut feeling

A green test run proves nothing. I learned that twice, expensively. So every change is verified against the live system before it counts as done. That is what makes agent-assisted development dependable.

Role
AI product engineer / fullstack
Focus
Product end to end, AI-assisted delivery
Location
Berlin · remote EU
Available
Open to talk now · start after notice period
Languages
German (native) · English
Model
Employment or freelance
Source code
Open source on GitHub · production repos on request
One-pager as PDF
Email me
GitHubdomenicmoran@gmail.com
Contact

Let's build something

A concrete role, a project enquiry, or just a technical question: I reply within 24 hours.

domenicmoran@gmail.com

Deliberately no form: that would need a delivery service as a data processor and an endpoint that can fail. A mail address can do neither, and you keep a copy of your message in your own sent folder.

GitHub

What helps me in a first email

  • What it is about: role, project or question
  • What you are building and with what
  • How soon you want to start
  • For roles: the salary range, so we both save time
Response time
Usually under 24 hours
Languages
German · English
Location
Berlin · remote EU