Skip to content
Domenic Moran · BerlinAI Product Engineer

Finished products, not prototypes.

I’ve built more than ten systems in production since six months, which I run under the brand Moran Software: apps in both stores, a multi-tenant SaaS with statutory fiscal signing, a learning platform with exams and certificates, an autonomous agent. Available to buy: MFC, the desktop application for chat, agents, tools and backlog, €49.99 one-time, no subscription.

Three of the more than ten production systems run right here in the browser: try the prayer times, the daily macros and the checkout table without a single request leaving it.

systems in production
10+
commits since March 2026
6,858
API routes (MenuCloud)
1,281
test cases (MenuCloud)
7,800+
Who I am

Four years learning. Six months shipping.

Domenic Moran

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: more than ten production systems in six months, 19 public store listings across both stores (14 on Google Play, five on the App Store) and eight apps with an open Apple review, all eight already live on Google Play (as of 6 September 2026), one of the systems 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 whose tests all passed but 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 since March 2026alongside a full-time job
6,858
systems in productionall built alone
10+
store listings live14 Play, 5 App Store
19
self-taught sinceMeta & Udemy certificates
2022

Measured on 1 October 2026 through the GitHub API, with git rev-list --count across all 17 repositories: the six monorepos behind MenuCloud, Salati, NOURI, BitDojo, Dartile and LexiPulse, this site and the four published packages. Counted on the main branch, and only what is actually on GitHub. Local commits do not count. The number therefore carries its measurement date rather than a promise: it is refreshed by hand, not continuously. It keeps growing, so any deviation is higher, not lower.

Path

  1. since April 2026

    Founder & sole developer

    MenuCloud, sole proprietorship, Berlin

    Building and running more than ten 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 more than ten systems in production and a git history anyone can check.

  3. since March 2018

    Full-time in public service

    Public sector, Berlin

    Full-time role in public service, alongside which more than ten systems were built.

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.

Products

My products

Autonomous apps and micro-SaaS from Berlin, which I run under the brand Moran Software. Every system runs in production, all built and operated by one person, from the first line to the store review.

MFC – Moran Fleet Control

Chat, agents, tools and backlog in one interface, local, no subscription.

€49.99 one-time, no subscription

Buy MFC
Selected work

More than ten systems in production, all built alone.

No practice projects, no tutorial clones. More than ten systems with real users, real payments or real legal obligations. I owned each one from the first line to the store review.

00

Moran Fleet Control

Live with buy button2026

The one application for the builder’s day: LLM chat, agents, tools, backlog, local, no subscription

Sole developer · product, code, sales, legal

Dashboard · web preview
The MFC dashboard in the web preview: the demo notice at the top, the status cards for core status, router providers, micro-SaaS modules and open items, and the grid of the twelve systems from chat to vault below.

The problem

A builder’s working day is spread across ten tools: a terminal for agents, tabs for models, spreadsheets for the backlog, folders for projects. Every switch costs context, and every cloud layer that rides along costs trust and money.

The solution

A desktop application (Windows, macOS, Linux) plus a web build: multi-LLM router with six providers, agents over the local Claude CLI (permissions, MCP, skills and memory are adopted unchanged), eleven micro-SaaS tools, project browser with git status, backlog of all projects, marketing pipeline with hard rate limits, and a vault that sits AES-256-encrypted in the OS keyring. 49.99 euros one-time, no subscription.

The hard part

Take over Claude Code without duplicating it

Whoever leaves the terminal does not want to set anything up again. Instead of rebuilding permissions, MCP servers and skills, MFC runs the local Claude CLI as the agent backend. The existing setup keeps applying unchanged. The stream of 204 events per session is rendered in the interface, with abort and a live log. Where something cannot work without a key, the interface says so honestly: simulations are marked as such.

  • Claude Code takeover: permissions, MCP, skills and memory are read and used unchanged
  • Chat with model choice per message, streaming, history and cost log on the device
  • Eleven micro-SaaS modules, eight run directly in the browser, three over server or desktop
  • Supervisor loop: Anthropic plans and checks, DeepSeek executes, hard-capped at three rounds
  • Mobile companion app (Android/iOS) paired by code and secret over its own relay
  • Clean-room distribution: no founder data in the package, setup wizard, zero-personal-data scanner
  • Windows installer and Linux bundles built locally, web live at mfc.domenicmoran.de
LLM providers
6
micro-SaaS modules
11
lifetime, no subscription
49.99 €
desktop platforms
3
01

Salati

Live in both stores2026

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

Sole developer · product, code, stores, legal

  • The prayer-times view: above the list an image of the Kaaba with the current time and a countdown to the next prayer, below it the five daily times with the next one highlighted and the Hijri date.
    Prayer times · computed locally
  • The Quran reader on the phone: the Arabic verse set large, transliteration and German translation below it.
    Mushaf reader · offline
  • The question-answering model replies with its source named and a note that the answer is AI-assisted.
    AI on the device · with source
  • The Qibla compass shows the prayer direction with the bearing in degrees and the distance to Mecca.
    Qibla · sensor and location
  • Prayer tracking: a tick per day and prayer, with the streak of consecutive days above.
    Tracking · streak
  • The Quran reader on a television: the Arabic verse set large, transliteration and translation below, remote-control hints at the bottom.
    Android TV · Leanback
  • The television home screen with tiles for prayer times, Quran and the study area, one of them showing the focus ring.
    Android TV · focus navigation
1 of 7

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 four device classes: phone, tablet, Android TV and Wear OS. Prayer times are computed locally, the full reader with multiple reciters and translations works offline, and the question-answering search runs entirely on the device. No query ever leaves the phone.

The hard part

Speech recognition for Quran 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.

A year of prayer times, computed right here

 

Not a screenshot and not a re-creation: this panel loads the same library that runs in the shipped app. Every stroke is one day, every line one prayer time. The switch on the right is where this got genuinely hard in production.

“as the app ships” uses twilight angle here

Fajr
 
Sunrise
 
Dhuhr
 
Asr
 
Maghrib
 
Isha
 

Spread between the rules

Above roughly 48° the sun never drops far enough below the horizon in summer, and Fajr and Isha are no longer well defined. The three common rules then drift apart: in Berlin, in June, by more than two hours. A user report saying “the prayer times are wrong” led exactly here. The app picks the twilight-angle rule, not because it is more correct, but because it matches what users compare against. In Tromsø even that leaves the days shown above without a result: the night the calculation refers to does not happen there.

adhan 4.4.4 (MIT), method 13 Diyanet, school 0 Shafi. 8,760 points in time, computed in the browser, without a single request leaving it. This is exactly how the app computes when there is no network.

  • Four device classes from one monorepo: phone, tablet, Android TV, Wear OS
  • Question answering on the device: own corpus, own ranking, no cloud call
  • Whisper-based recitation checking with verse-conditioned prompting
  • Complete Mushaf reader: four typefaces, tafsir, translation, word-level timestamps
  • A German podcast on the Arabic of the Quran: 68 episodes, over ten hours, 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
02

MenuCloud Berlin

Live in production2026

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 listing shown is a demo entry.
Discovery app · demo data

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.

Two more demos in the browser

A day, put together

4 / 12

Twelve dishes from the catalogue, with the per-portion values stored there. Set a target and let it run: it checks all 4,096 possible combinations and takes the one with the most protein that stays under the target.

2,095 kcal, 198 g protein

kcal
2,095
protein
198 g
carbs
213 g
fat
42 g
fibre
42 g

All 4,096 combinations, calories across, protein up

chosenthe best possible at that calorie countTarget

protein 39 % · carbs 42 % · fat 19 %

105 kcal below the target

Values from the NOURI catalogue (11,892 recipes, these twelve are the curated ones). Energy split via the standard 4/4/9 kcal per gram. The target is the visitor’s: in the app it comes from the profile, and one invented here would be the only figure on this site without evidence.

The checkout table, computed here

20 routes checked

No lookup in a stored table: this panel loads darts-checkout from npm, the same package that runs in the app. Every move of the slider searches all routes to that remainder and ranks them the way they are thrown: start high, finish on a large even double, and go for the bull only when there is no way around it.

Out mode

The suggestion

T20 T19 D12

Same length, different order

  • T19 T20 D12
  • T20 T15 D18
  • T19 T16 D18

Every remainder from 2 to 170, coloured by how many darts it takes; the gaps are the bogey numbers

Exactly seven remainders below 170 cannot be finished with three darts on a double out: 159, 162, 163, 165, 166, 168, 169. They are nowhere in the code as a list, they fall out of the search; the library keeps them only as a fixture in the test.

darts-checkout 1.0.0 (MIT), computed in the browser without a single request leaving it. The same package is public on npm: install it and you get the same strings, which is how you check that this is computed rather than read off.

More projects

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.

    • n8n workflows with self-healing
    • Cooldown and 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.

daysfrom the first commit on 16 April 2026 until the verification date, 1 October 2026
168
versions shipped1.0.0 to 1.51.0, listed in the app’s own changelog
70
per version on average168 days divided by 70 versions
58 h

Figures for Salati, counted on 1 October 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 evidence 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, four device classes
TypeScript
Strict everywhere, 0 errors as a merge gate
Motion & interaction
Reanimated 4, Framer Motion
Core Web Vitals
Lighthouse cron against production, per‑route bundle budget
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
RLS per tenant, 818 migrations (MenuCloud)
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
n8n workflows with self-healing

AI integration

From the agent pipeline in my editor to the answer the user’s phone finds without a network.

Agent orchestration
Sub-agents, tool pipelines, loops
On-device inference
whisper.rn, speech recognition without a network
RAG & retrieval
Own corpus, granularity measured
Prompt engineering
Verse conditioning beats model size
Evaluation
Local iteration against the same Whisper model
AI regulation (EU AI Act)
Art. 50 disclosure as a gate
For recruiters & CTOs

The essentials in two minutes

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

More than ten 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.

The eight case studies

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”.

MenuCloud in detail

I prove it rather than claim it

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.

“Published” is not proof

I know the way through the app stores

70 versions shipped for Salati alone, plus 19 public store listings across both stores and eight more apps with an open Apple review right now (as of 6 September 2026). 14 languages, four device classes from phone to television. Rejections in review, age ratings, privacy forms and signing chains are routine here, not new ground.

Salati in detail

I treat regulation as part of the product

German fiscal requirements under § 146a AO, GDPR processing agreements, disclosure duties for AI features. I know these from shipping them with customers, not from a summary. Handle them after launch and you build the thing twice.

German till law in practice

I work with agents without handing over control

The leverage is not typing speed. It is context, written-down conventions and review loops a model cannot talk its way past. I let agents draft. The architecture, the boundaries and the sign-off stay with me.

verified-done on GitHub

Three of the more than ten production systems run right here in the browser: try the prayer times, the daily macros and the checkout table without a single request leaving it.

Role
AI Product Engineer / Full-stack
Focus
Product end to end, AI-assisted delivery
Looking for
A product team where I take a feature all the way into production
Location
Berlin · remote in the EU · hybrid
Available
Open to talk now · start within three months
Languages
German (native) · English
Model
Permanent employment
Salary
€55–70k, depending on scope
Source code
Open source on GitHub · production repos on request
Contact

Let’s build something

A concrete role, a question about one of the projects, or just a technical question: I usually reply within 24 hours.

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.

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: your salary range, so we both save time
Response time
Usually under 24 hours
Languages
German · English
Location
Berlin · remote in the EU · hybrid