# riemer.fyi — full content Canonical text of https://riemer.fyi. The site itself is a single conversational page, so this file is the complete source rather than a summary of one. Generated from the site's own content at build time. Contact: hello@riemer.fyi · Book a call: https://calendar.app.google/zEwQzZiNxeTeViFQ7 --- # About Riemer Building digital experiences with a brutalist edge Location: Netherlands I'm a developer focused on creating honest, functional web experiences. I believe in stripping away unnecessary complexity and letting the work speak for itself. Currently exploring the intersection of AI and web development, building tools that feel natural and powerful. --- # Projects ## riemer.fyi - Year: 2026 - Status: live - Stack: Next.js 16, React 19, Tailwind v4, TypeScript - URL: https://riemer.fyi A brutalist portfolio site with an integrated AI chat interface. Built to showcase projects while experimenting with conversational interfaces. The site uses a single source of truth for content - markdown files that power both the static pages and provide context to the LLM. ## Yoursafe - Client: Yoursafe - Year: 2026 - Status: In Progress - Stack: OpenClaw, TypeScript, Python, PostgreSQL, Anthropic Claude, Terraform, GitLab CI - Tags: AI, Agents, Financial Services, Compliance, Audit, Governance, Netherlands A governed AI-agent platform for a Dutch financial institution. Agents that do real operational work inside a supervised environment — where the hard part was never making the agent work, but making it something a compliance officer can sign off on. ## Role **Fractional CTO & Agent Governance Architect** ## The Context Getting an AI agent to do useful work is now the easy part. Getting one approved to run inside a regulated financial institution is a different problem entirely. A supervised institution cannot deploy a system that acts on customer data and internal systems unless it can answer, for every single action: who authorised this, what exactly did it do, what did it see, and can we prove it after the fact. Most agent frameworks are built for speed of demo, not for that question. They log prose, not evidence. They let the model reach for any tool it likes. They have no notion of who approved what. The engagement is about closing that gap — designing the layer between "the agent works" and "the agent is allowed to work". That layer is where nearly all the real engineering lives, and it is almost entirely absent from the off-the-shelf agent stack. ## Technical Implementation ### Governed agent runtime Agents run as a fleet of instances built on an open agent runtime, extended in-house. The extension model separates three things that are usually tangled together: - **Extensions** — compiled code that adds a channel, a tool, or registers a lifecycle hook. Global to the runtime image, so a governance hook cannot be selectively disabled. - **Skills** — task flows loaded from disk, selected per agent type. - **Profiles** — the prompt, the tool allowlist, the skill selection and the model pin for one agent type. The decision rule is deliberately blunt: compiled and global means extension, per-task means skill, selects-and-configures means profile. Governance controls are always extensions, so they are never a per-agent opt-in. ### The audit spine Every governed action is captured as a structured event, redacted, conformed to a schema, and shipped to an audit store. The exporter is registered as a single global lifecycle hook rather than a per-agent integration — an agent cannot run without it and cannot turn it off. The design principle that took the most iteration: **nothing may fail to show up in the trajectory.** An early design quarantined events that failed schema validation. In practice that produced a graveyard — a broken producer and an idle agent looked identical in the audit store, which is exactly the ambiguity an audit trail exists to eliminate. The replacement degrades gracefully: a validation failure costs a *field*, never the *event*. The schema stays a real contract, but a producer bug can no longer make evidence silently disappear. ### Human-in-the-loop by construction Risky actions are gated on an allowlist with an ask-on-miss default, surfaced as native approval buttons in the chat tool staff already use. Approvals are dispatched and audit-logged as first-class events, so "who clicked approve" is part of the record rather than something reconstructed from logs later. The browser tool drives a real browser through its accessibility tree rather than raw coordinates. That is partly reliability, but mostly auditability: coordinate clicks and arbitrary script evaluation are the two actions that make a trajectory unreadable after the fact, so they are deliberately kept off the allowlist. ### Fail-closed redaction PII redaction runs as a fail-closed hook on write, not as a post-processing step. Anything an agent commits to durable memory, and anything it nominates for promotion, passes the redaction library first. Fail-closed is load-bearing here: if the redactor cannot decide, the write does not happen. ### Change as a reviewed diff Agents can nominate a durable learning for promotion to their whole agent type. That promotion opens a merge request against a version-controlled runtime repository rather than mutating anything live. A behavioural change to an entire class of agents is therefore a reviewed diff with an author, a reviewer and a merge commit. This is the organising principle of the whole platform: **every artifact that configures or governs the fleet is version-controlled and reviewed, and the review is the audit gate.** Source control is not just where the code lives; it is where the compliance trail begins. ### Fleet and control plane A control plane holds the declared state of the fleet and converges the real fleet toward it. Access is through a governed API with explicit token classes, so there is exactly one path to the registry and the rules that govern that path are the rules for everyone. Infrastructure and machine baselines are declared and pushed, not hand-configured. ## Compliance Stakeholders to Consider Agent governance in a supervised financial institution has more stakeholders than a typical build, and they want different evidence: - **Compliance and risk** — needs to know which actions are gated, who can approve them, and what the agent is structurally prevented from doing. Answered by the profile allowlists and the approval gates, not by prompt instructions. - **Internal audit** — needs a reconstructable record after the fact. This is the audit spine's entire purpose, and it drives the "degrade a field, never drop an event" rule. - **Information security** — needs the supply chain closed. No public plugin marketplace; only vetted in-house or pinned code enters the runtime image. Governance extensions that touch the privacy boundary are tagged so they can never be accidentally published upstream. - **Data protection (GDPR/AVG)** — an audit trail that captures everything an agent saw is itself a rich store of personal data. Redaction has to happen before the event reaches the store, and retention on the store is a design decision, not an afterthought. - **Prudential and conduct supervision** — a Dutch financial institution answers to DNB and the AFM. The relevant question is not whether AI is permitted, but whether the institution retains demonstrable control over an automated process. Every control above is built to be shown, not just asserted. - **Operational resilience (DORA)** — agents acting in operational systems are ICT-supported processes. Failure modes, rollback, and the ability to stop the fleet are requirements, not features. - **Segregation of duties** — an agent must not be able to approve its own action, or promote its own behaviour change without human review. This is enforced structurally, in the control plane and the merge gate. ## What I Build The governance layer: the audit and trajectory spine, the redaction hooks, the approval gates, the tool allowlist model, the profile/skill/extension boundaries, and the review-as-audit-gate workflow that ties them together. Plus the fleet control plane that keeps a declared fleet and a real fleet in agreement. **The interesting engineering in agentic AI is no longer the agent. It's everything that makes the agent accountable.** ## moodsai.ai - Client: Moods AI - Year: 2025-2026 - Stack: Django, Next.js, PostgreSQL, OpenAI, Auth0, Whereby - Tags: AI, Mental Health, Telehealth, GDPR, Privacy, Netherlands - URL: https://moodsai.ai A telehealth platform for mental health patients in the Netherlands, combining video therapy sessions with AI-powered support tools. Built with privacy-first architecture in full compliance with Dutch and European healthcare regulations. ## Role **Fractional CTO & Privacy Infrastructure Lead** ## The Problem Mental health patients need continuous support between therapy sessions, but therapists can't be available 24/7. Traditional therapy notes are scattered, progress tracking is manual, and patients often struggle alone during critical moments. Meanwhile, the regulatory landscape is hostile to innovation: GDPR special category data, medical device regulations, professional liability concerns. Most platforms either ignore compliance or become so conservative they're useless. **The challenge: Build AI that actually helps—while respecting privacy and meeting strict compliance requirements.** ## The Solution A telehealth platform where: - **Therapists conduct video sessions** with integrated note-taking and session recording - **AI assists (doesn't replace)** by transcribing sessions, summarizing conversations, tracking progress - **Patients get 24/7 support** through AI chat that understands their context and therapy goals - **Privacy is architected-in**, not bolted-on - **Compliance is embedded** in every feature from day one ## What MoodsAI Does ### For Therapists **Video Therapy Sessions** - Whereby-powered video calls with GDPR-compliant infrastructure - Real-time session notes with AI-assisted transcription - Automatic session summaries highlighting key insights and action items - Patient progress tracking across sessions - Document management for treatment plans and assessments **AI Co-Pilot** - Transcription of therapy sessions (with explicit patient consent) - Pattern recognition across multiple sessions - Risk flag detection for concerning language or behavior - Treatment plan suggestions based on clinical guidelines - Administrative task automation (scheduling, reminders, follow-ups) ### For Patients **Between-Session Support** - AI chat that knows your therapy context (with your permission) - Mood tracking and journaling with AI insights - Coping strategy reminders based on your therapy sessions - Crisis resources and escalation to human support when needed - Progress visualization over time **Privacy Control** - Granular consent for each AI feature - View and delete your data anytime - Export your complete history - Choose what therapist can see vs. private journaling ## Privacy & Compliance Architecture ### GDPR Special Category Data Handling - **Purpose limitation**: Each AI feature requires explicit consent - **Data minimization**: Only process what's absolutely necessary - **Right to erasure**: Complete data deletion on request - **Data portability**: Export in machine-readable format - **Automated processing transparency**: Clear explanations of AI decisions ### Security Infrastructure - **End-to-end encryption** for all therapeutic conversations - **Data anonymization** for AI training (zero patient PII) - **Role-based access control** with audit logs - **SOC 2 Type II compliant** infrastructure - **Penetration testing** and vulnerability scanning - **Incident response plan** with breach notification procedures ### Medical Device Compliance (Netherlands/EU) - **Class I** medical device classification (wellness app with AI) - **Clinical safety documentation** for AI features - **Risk management** per ISO 14971 - **Post-market surveillance** with adverse event tracking - **Quality management system** aligned with ISO 13485 principles ### Professional Liability Protection - **Clear AI limitations** communicated to users - **Human-in-the-loop** for all clinical decisions - **Therapist oversight** of AI suggestions - **Crisis escalation** to human professionals - **Informed consent** for all AI features ## Technical Architecture ### Backend (Django + PostgreSQL) - **User management**: Auth0 integration with role-based permissions - **Session management**: Video session orchestration with Whereby API - **AI integration**: OpenAI API with privacy-preserving prompts - **Document storage**: Encrypted file storage for therapy materials - **Audit logging**: Complete activity tracking for compliance - **Background jobs**: Huey for async task processing (reminders, summaries) ### Frontend (Next.js) - **Patient portal**: Mood tracking, journaling, AI chat interface - **Therapist dashboard**: Session management, notes, patient overview - **Admin panel**: User management, compliance reporting, analytics - **Real-time updates**: WebSocket for live session features - **Responsive design**: Mobile-first for patient accessibility ### AI Features - **Session transcription**: Speech-to-text with speaker diarization - **Conversation summarization**: Key insights extraction from sessions - **Mood pattern analysis**: Trend detection across mood journal entries - **Risk detection**: Flag concerning language patterns for therapist review - **Personalized coping**: AI suggests techniques based on therapy plan ### Privacy-First AI Design - **No fine-tuning on patient data**: Zero-shot and few-shot prompting only - **Anonymized examples**: All training uses synthetic or fully anonymized data - **On-premise LLM option**: For organizations requiring air-gapped deployment - **Audit trail**: Every AI interaction logged with purpose and consent - **Human review**: Therapists approve AI-generated content before patient sees it ## Impact **For Patients:** - ✅ **Continuous support** between therapy sessions - ✅ **Better progress tracking** with AI insights - ✅ **Reduced anxiety** from 24/7 access to coping tools - ✅ **Full privacy control** over their data **For Therapists:** - ✅ **Less admin work**: AI handles transcription, summaries, scheduling - ✅ **Better insights**: Pattern recognition across sessions - ✅ **Risk awareness**: Early detection of concerning changes - ✅ **More time for patients**: Focus on therapy, not paperwork **For the Organization:** - ✅ **Regulatory confidence**: Built-in GDPR and medical device compliance - ✅ **Professional liability protection**: Human-in-the-loop safety measures - ✅ **Scalable infrastructure**: Django + PostgreSQL for growth - ✅ **Audit-ready**: Complete documentation and logging ## What I Built Full-stack telehealth platform with privacy-first AI infrastructure. Designed Django backend with Auth0 authentication and Whereby video integration. Built Next.js frontend with patient and therapist portals. Implemented AI features with OpenAI integration using privacy-preserving prompts. Created GDPR compliance framework with consent management and data deletion. Developed medical device documentation for Netherlands/EU approval. Deployed secure infrastructure with encryption, audit logging, and automated testing. **Proving that AI can enhance mental healthcare—without compromising privacy or professional responsibility.** ## Sarah - Client: participatie.ai - Year: 2025-2026 - Status: Production - Stack: FastAPI, LangGraph, Supabase (self-hosted), PostgreSQL, Redis, Celery, Next.js, Twilio, Google Gemini, Terraform, Langfuse - Tags: AI, Social Impact, WhatsApp, Integration, GDPR, AVG, Netherlands - URL: https://participatie.ai A WhatsApp AI assistant helping newcomers navigate the Dutch governmental system, and a municipal portal for the case managers responsible for them. Sarah meets people in their own language — by text or by voice — and does it on infrastructure that keeps their data in the Netherlands. ## Role **Fractional CTO & AI Build Partner** ## The Context Newcomers to the Netherlands face a labyrinth of government requirements: deadlines, appointments, paperwork, obligations under the Participatiewet. The system is written in Dutch, for Dutch speakers, with Dutch assumptions. Miss a letter you could not read, and the consequence is a fine or a stalled integration track. The barrier is rarely willingness. It is communication. When someone cannot read the letter, navigate the portal, or call the helpline, the process is set up for them to fail — and the cost of that failure lands on both the person and the municipality that is legally responsible for their track. So the work has two audiences, and they are not the same. The newcomer needs to be met in their own language on the app they already use. The municipal case manager needs an accountable record: who was told what, when, and what they answered. Sarah is one system serving both, and most of the interesting design decisions come from that split. ## Technical Implementation ### Conversational core An event-driven backend on FastAPI, with LangGraph orchestrating conversation state and Google Gemini as the language model. Inbound messages — from WhatsApp via Twilio, or from the web chat — land on a webhook, publish to a Redis event bus, and are picked up by a consumer that runs the graph. Responses go back out over Socket.IO to web clients or Twilio to WhatsApp. Celery handles the scheduled side: reminders, due inbox items, recurring check-ins. Audio is a first-class path, not a bolt-on. Many users have limited literacy in their own written language, so speech-to-text on the way in and text-to-speech on the way out are core to the design rather than an accessibility afterthought. ### The Translation Router Every outgoing message passes through a single mandatory checkpoint before dispatch. It validates the interactive UI against WhatsApp's hard limits, translates message content sequentially with conversational context, translates the UI itself under a JSON schema so the model cannot return an unrenderable shape, and validates the result. Making this a chokepoint rather than a convention is the whole point. A translation path that *usually* runs is a path that will one day send Dutch bureaucratic language to someone who cannot read it. Sarah currently operates in Dutch, English, Arabic, Tigrinya and Farsi. ### Inbox and obligation tracking Government obligations are modelled as an inbox of scheduled items — notifications, reminders, questions — walked in a deterministic linear order. Items delivered out of band by the scheduler are reconstructed into the model's context on the next turn, so the assistant is never unaware of something it already sent. At most one open question per user is enforced by a database constraint rather than application convention. On top of this sits participation-hours tracking under the Participatiewet: a recurring check-in where Sarah logs hours toward a client's statutory norm, including the municipality's own eligibility rules about what counts. ### One source of truth for shared logic Logic that both the Python backend and the portal frontend need lives in shared `SECURITY DEFINER` Postgres functions rather than being implemented twice. Portal callers arrive as authenticated JWT users and are gated in-body by an access check; the backend is trusted. Execute is explicitly revoked from the anonymous role, because Supabase's default privileges grant it and revoking from `PUBLIC` alone is not enough. The graph-walk that advances a client's inbox is atomic Postgres functions granted only to the service role, with the one portal-facing operation gated separately. Rules that protect a client — a required question cannot be skipped or deleted — are enforced in the database, not only in the UI that happens to be in front of it. ### Municipal portal and multi-tenancy A Next.js portal gives municipalities and case managers their view: client overview, inbox management, document handling, hours verification. It talks to the database directly under row-level security rather than through a bespoke backend API, so the access rules are defined once, in one place, and cannot drift between two implementations. Multi-tenancy is modelled on organisations and case managers, so several municipalities share the platform without sharing data. Staff-only actions — such as a case manager's sign-off on logged hours — are enforced with role gating and column-level grants, so a client structurally cannot verify their own record. ### Infrastructure and data residency The platform moved off managed cloud Supabase onto **self-hosted Supabase on Scaleway in the Netherlands**, provisioned with Terraform. This was a compliance decision before it was a technical one: the data is about vulnerable people's immigration status, language and municipal obligations, and it now sits on infrastructure in a known jurisdiction under a known operator. The migration cost real tooling. The managed provider's admin API — migrations, advisors, log access — does not exist against a self-host, so migration application, schema linting and log access all had to be rebuilt around a tunnelled connection and direct server access. Worth it, but a genuine trade, and the kind of trade worth naming out loud rather than discovering afterwards. ### Observability and failure behaviour LLM tracing runs through Langfuse, with each chat turn wrapped in a single trace so the graph run and the pre/post translation calls nest underneath it. When something goes wrong, the rule is that **errors never reach the user as a stacktrace or as silence** — there is a structured error taxonomy, a single reporting chokepoint, and a fallback notice held statically in every supported language. Deliberately statically: the thing that failed may well be the translation path itself. ## Compliance Stakeholders to Consider This project has more parties with a legitimate claim on the data than a typical consumer product, and their interests genuinely conflict: - **The client (data subject)** — a newcomer, often in a vulnerable position, whose data touches immigration status, language, and municipal obligations. Much of it is special category data under the AVG. They also need to know they are talking to an AI, and to reach a human when the case needs one. - **The municipality (gemeente)** — the data controller and the party with the statutory duty under the Participatiewet. They need an accountable, auditable record of what was communicated, and they need their own clients' data segregated from other municipalities'. - **The case manager** — needs enough visibility to do their job, and no more. This is what drives row-level security as the access model rather than a permissive backend API. - **Data protection (AVG/GDPR)** — purpose limitation and minimisation on a conversational system that will happily be told more than it needs. Data residency, retention, and a DPIA are live concerns, not paperwork — which is what drove the move to self-hosted infrastructure in the Netherlands. - **The AI Act** — a system that informs people about their legal obligations has transparency duties, and its failure modes matter. Hence disclosure that it is an AI, human escalation for complex cases, and the deliberate choice not to let it invent an answer about someone's legal position. - **Segregation of duties** — a client cannot verify their own participation hours; a case manager cannot silently delete a required obligation. Enforced in the database, where it holds regardless of which client is talking to it. ## What I Built Full-stack AI system from concept to production. Multi-agent conversation orchestration with LangGraph. WhatsApp and web channels with an audio-first design. A mandatory translation and UI-validation checkpoint. An obligation-tracking inbox with database-enforced invariants. Municipal multi-tenancy with row-level security and shared Postgres functions as the single source of truth. Migration to self-hosted, Terraform-provisioned infrastructure in the Netherlands for data residency. LLM observability and an error-handling spine that fails visibly rather than silently. **The barrier to integration is communication, not people. That is an engineering problem — and it is one you have to solve without becoming careless with the data of people who cannot afford your carelessness.** Have a look at [participatie.ai](https://participatie.ai) to see the project. ## betterbooking.ai - Client: WinWin Technologies - Year: 2024-2026 - Stack: Next.js, LangGraph, Supabase, OpenAI, Google Gemini, Puppeteer - Tags: AI, Negotiation, Consumer Advocacy, LLM - URL: https://betterbooking.ai AI negotiator that levels the playing field between consumers and vendors on platforms like Airbnb. An LLM-powered system that negotiates on behalf of users to secure better prices and terms. ## Role **AI Build Partner & Fractional CTO** ## The Problem Online marketplaces favor vendors with sophisticated pricing algorithms and psychological tactics. Individual consumers lack the time, skill, and data to negotiate effectively, resulting in systematic overpayment. ## The Solution An AI negotiation agent that: - Analyzes pricing patterns and market data from 25+ real successful negotiations - Deploys contextual backstories and value propositions as bargaining chips - Maintains conversational flow with hosts using natural language - Applies proven negotiation strategies (Aggressive 30%, Standard 20%, Conservative 10% opening discounts) - Enforces fundamental negotiation principles (monotonic progression, never exceeds max budget) ## Key Deliverables - **Multi-Strategy Negotiation Engine**: 3 configurable strategies with distinct personalities and tactics - **LangGraph State Management**: Robust conversation flow with decision nodes (analyze → craft response → accept/reject) - **Real-Time Browser Automation**: Puppeteer-based integration with Airbnb messaging - **Context-Aware Messaging**: 30 natural backstories matched to booking details, 12 value-add offers - **Production Database**: Supabase with full analytics tracking, strategy performance metrics, and conversation history - **Web Application**: Next.js 16 frontend with real-time negotiation monitoring ## Real-World Performance - **60% success rate** when opening 20-30% below asking price - **15-25% average discount** achieved - **2-3 rounds typical** to close deal - **Key tactics validated**: Budget constraints + flexibility + social proof + upfront payment ## Impact Democratizing negotiation power for everyday consumers. Turning asymmetric marketplace dynamics into fair, data-driven exchanges. Successfully deployed with active users negotiating Airbnb bookings across Europe and North America. **The ultimate consumer advocacy tool: an AI that never sleeps, never gets emotional, and always plays to win.** Check out [betterbooking.ai](https://betterbooking.ai) to see it in action! --- # Notes and positions ## What does it mean to be an AI Build Partner? - Tags: philosophy, AI, fractional-cto Most people hire developers to write code. I build products. An AI Build Partner means I'm in the trenches with you—not just shipping features, but thinking about the system as a whole. What does this actually need to do? What will users care about six months from now? What compliance landmines are we about to step on? The AI part? I use LLMs, automation, and intelligent tooling to move faster than a traditional dev team, but I don't cut corners. I build production systems that can scale, pass audits, and won't embarrass you. I'm not your employee. I'm your co-conspirator with enough distance to tell you when an idea is bad. ## AI's role in society - setting people free from repetitive work - Tags: philosophy, AI, society, automation, ethics We built computers to do repetitive tasks for us. Then we put people in jobs doing repetitive tasks on computers. Think about it: back-office workers, data entry clerks, invoice processors. The computer was supposed to free us from drudgery. Instead, it created an entire economy of people being human APIs—mindlessly copying data between systems, filling forms, following rigid workflows. We made it worse. AI has a chance to actually set us free. To automate the repetitive, the boring, the soul-crushing tasks that shouldn't require human creativity in the first place. **The creative and fulfilling tasks should be done by people.** Strategy. Design. Teaching. Care. Problem-solving. Building relationships. These are human work. But we're in a transition period. And transitions hurt. AI will disrupt jobs—especially jobs that shouldn't have existed in the first place. We need to think carefully about who gets impacted and whether we're okay with that. I build AI systems that eliminate repetitive work. Invoice processing. Document classification. Data extraction. The stuff that makes people numb. But I also think about: who loses their job? What happens to them? Are we building a better world, or just optimizing for shareholder value while people suffer? The goal isn't "AI that replaces humans." It's "AI that frees humans to do human things." We should automate with purpose—and responsibility. ## The attention economy creates perverse incentives - Tags: business-model, ethics, attention-economy When your business model is "maximize time on platform," you're incentivized to make your product worse for users. Attention-based revenue creates a direct conflict: - **User's goal**: Get value, then leave - **Company's goal**: Keep you scrolling indefinitely Every product decision becomes: "Does this help users or trap them?" Guess which one pays the bills. **I refuse to build products optimized for attention.** If your success metric is "time on site," you're admitting your product isn't valuable enough to charge for. Subscription models align incentives: pay for the product → product optimizes for user satisfaction, not engagement. ## My background - from synthetic biology to AI - Tags: background, education, journey I started in biotechnology at Wageningen University. Did exchanges at Cornell (CompStat, Biometry) and Utrecht (Complex Systems). Competed in iGEM twice—the only bachelor student on the team both times. Then I pivoted. Hard. Moved to Singapore for a Master's in AI at NTU (ranked #12 globally). The program kicked my ass in the best way. Deep technical foundations across machine learning, NLP, computer vision, systems architecture. While studying, I couldn't sit still. Started MAOTO, a deep-tech AI infrastructure company. Won Antler prizes, secured university grants. Built the thing, learned a ton, moved on. Now I'm a deeply technical executive. I can code, sell, and plan. I've built companies, worked in venture capital, shipped production systems across three continents. The through-line? I'm an entrepreneur at heart. I love building things that matter, telling the narrative, making people believe in one goal. No bullshit, just results. Biotechnology taught me systems thinking. AI taught me how to build at scale. Entrepreneurship taught me everything else. ## I read these chats. I might bring them up on our call. - Tags: contact, process, authenticity Fair warning: I store these conversations. Not for surveillance. For context. If we end up on a call, I'll have read what you wrote here. I might reference it. I might ask follow-up questions based on what you shared. This isn't a black box you're shouting into. It's the start of a real conversation. So be honest. Be specific. Tell me what you actually want to build, not what you think I want to hear. If your pitch changes between the chat and the call, that's a red flag. ## How do you approach compliance engineering? - Tags: compliance, engineering, GDPR, regulations Compliance is engineering, not paperwork. Most people treat compliance as something you do after building—hire lawyers, fill out forms, hope for the best. That's backwards and expensive. I treat compliance as an architectural constraint from day one. GDPR? That shapes your database schema, your API design, your entire data lifecycle. EU AI Act? That determines how you structure your LLM pipelines and log every decision. MDR? That's your software development lifecycle, testing strategy, and quality management system. The trick is knowing which regulations actually matter (most don't) and which ones will kill your product if you ignore them (a few critical ones). I've built systems that pass HSA audits in Singapore, GDPR audits in Europe, and medical device certifications in the Netherlands. Compliance engineering means: build it right from the start, document as you go, and sleep well at night knowing you won't get fined or shut down. Not sexy, but it keeps you in business. ## Why compliance-first architecture? - Tags: compliance, GDPR, philosophy Compliance isn't a checkbox. It's architecture. Most teams build the product first, then panic about GDPR/HIPAA/MDR later. That's when they discover their entire data model is wrong, their AI training pipeline is a privacy nightmare, and fixing it means rewriting everything. I build compliance in from day one. Not because I love paperwork—I hate it—but because the alternative is worse: launch delays, costly rewrites, or worse, regulatory fines and reputation damage. Privacy-first architecture, consent management, audit trails, data minimization—these aren't features you bolt on. They're foundational decisions that shape your database schema, your API design, your entire system. Get it right from the start, ship with confidence. ## How NOT to reach Riemer - Tags: contact, linkedin, philosophy Don't DM me on LinkedIn. I think LinkedIn is an awful app. It doesn't help people get jobs or gigs. It's just a platform for showcasing and giving people a false sense of productivity. I call it sophisticated procrastination—like vacuuming your house when you really should be working. Maybe that's just me. But I'm not checking LinkedIn. If you want to work with me, email me. Or better yet, just start building something interesting and show me what you've made. ## What does a Fractional CTO do? - Tags: fractional-cto, services, leadership You need strategic technical leadership, but you don't need (or can't afford) a full-time CTO. That's where I come in. As a Fractional CTO, I'm your technical co-conspirator. I make the architectural decisions that matter, review what's being built, call out bad ideas before they become expensive mistakes, and keep the team moving in the right direction. I don't sit in every standup or review every PR—that's micromanagement. I focus on the decisions that have long-term consequences: tech stack choices, system architecture, compliance strategy, vendor selection, hiring plans. You get executive-level technical guidance without the executive-level salary. I'm fractional because I work with multiple clients, which means you benefit from patterns I've seen elsewhere without paying for me to learn on your dime. Remote-first, async by default, high-leverage work only. ## GDPR shifted power from companies to users - Tags: gdpr, privacy, data-protection "GDPR killed innovation" is the complaint. The data shows otherwise. **GDPR made it expensive to be careless with data. That's the point.** Before GDPR: companies collected everything by default, users couldn't see their data, consent was buried in 40-page ToS, no recourse when things went wrong. After GDPR: explicit consent required, right to access/deletion/portability, mandatory breach notifications, real penalties (up to 4% global revenue). **The innovation myth:** GDPR hurt lazy startups, not good ones. Privacy-by-design isn't impossible—it's engineering discipline. I've built systems under GDPR. It made me a better engineer. When you can't solve problems by hoarding data, you solve them with better architecture. GDPR didn't kill innovation. It killed bad innovation that should have died anyway. ## Riemer's hobbies and interests outside of work - Tags: hobbies, personal, creativity, community, interests, activities, free-time People often ask: what do you do for fun? What are your hobbies? What do you do when you're not working? Here's what I'm into outside of coding and building: **Dancing**: I dance West Coast Swing. This is how I made most of my friends, honestly. There's something about partner dancing that builds community differently—you learn to communicate non-verbally, trust quickly, and stay present. Plus it's just fun. I spend multiple evenings per week at dance socials. **Music**: I love love love music. I play the theremin (poorly, but enthusiastically). I listen to Moog while programming—analog synths, modular setups, electronic music, that whole world. There's a direct line between electronic music production and systems thinking. Both are about signal flow, modulation, and emergent complexity. **Painting & Drawing**: I've been painting for many years. I draw. I'm just a fairly visual person. When I'm thinking through system architecture or data flows, I sketch them out. Visual thinking helps me understand complex systems in ways that pure abstraction can't. Art, painting, drawing—it's all part of how I think. These aren't "hobbies" in the sense of weekend distractions or leisure activities. They're part of how I process the world. Dancing teaches rhythm and communication. Music teaches systems and feedback loops. Art teaches composition and negative space. All of it makes me a better builder. ## How do you approach testing of LLMs and agents? - Tags: testing, LLM, agents, evaluation, data-science I don't "prompt engineer." I rigorously test AI systems like any other software—with data, metrics, and statistical evaluation. **My approach:** **Synthetic datasets, not vibes.** I create test datasets with my clients that cover edge cases, failure modes, and expected behavior. We define what "good" looks like upfront, then measure against it. **Multiple prompts, multiple flows.** I don't tweak a prompt until "it looks good." I test variations systematically: different phrasings, different system prompts, different approaches. Then I evaluate which performs best on the metrics that actually matter. **Computational statistics, not guessing.** I have a background in data science and computational stats. I use it. Confidence intervals. Statistical significance. Distribution analysis. If you can't measure it, you can't improve it. **Proper evaluation frameworks.** I go far—and I mean *far*—beyond "yeah looks good." I build evaluation harnesses that automatically test LLM outputs against expected behavior, score accuracy, flag regressions, and track performance over time. **"Looks good" is not a test.** It's wishful thinking. Production LLM systems need the same rigor as any other critical software: reproducible tests, version control, regression detection, performance monitoring. If you're shipping AI agents to production and your testing strategy is "I tried it a few times and it seemed fine," you're gambling with your users' trust. I don't gamble. I test. ## Local AI Hosting: Privacy by Design - Tags: ai, privacy, infrastructure, compliance You don't have to send all your data to OpenAI or Anthropic. Local and dedicated hosting of LLM and AI systems is not just possibleit's increasingly practical. Whether you need sophisticated privacy controls, regulatory compliance, or just want to keep sensitive data in-house, self-hosted AI is a real option. Models like Llama, Mistral, and others can run on your infrastructure. Smaller, fine-tuned models can handle specific tasks incredibly well without the latency and privacy concerns of cloud APIs. For companies dealing with healthcare data, legal documents, or proprietary information, this isn't just nice to haveit's essential. I can help you evaluate whether local hosting makes sense for your use case, set up the infrastructure, and integrate it into your stack. Privacy doesn't have to mean sacrificing capability. ## Maintenance as a Service (and Graceful Offboarding) - Tags: services, maintenance, consulting, development, support, ongoing Yes, I offer maintenance services after building a project. I'm very happy to continue maintaining it as a service. After I build your project, you focus on growing your business while I make sure your infrastructure stays healthy, dependencies stay updated, security patches get applied, and small features get shipped without becoming bottlenecks. Think of it as having a dedicated senior engineer on retainer—without the full-time overhead. Maintenance includes: keeping dependencies updated, applying security patches, shipping small features, infrastructure monitoring, and general system health checks. And if push comes to shove, I'll help with offboarding too. When you're ready to bring on a new dev team, I'll explain the architecture, document the decisions, and make the handoff smooth. No gatekeeping. No artificial complexity. Just clean transitions and continuity. ## MDR/IVDR: Why medical device regulation exists - Tags: mdr, ivdr, medical-devices, compliance Move fast and break things is fine for social apps. It's criminal for medical devices. When medical devices fail, people die. That's not hypothetical—faulty pacemakers, inaccurate glucose monitors, contaminated implants, software bugs in ventilators. **There is no "fail fast, iterate" in medicine.** EU's MDR (Medical Device Regulation) and IVDR (In Vitro Diagnostic Regulation) require: - Clinical evidence for safety and performance - Post-market surveillance (monitoring doesn't stop after approval) - Risk-based classification - Full traceability Compliance feels hard because it *is hard*. Making medical devices is supposed to be hard. Medical device regulation exists because the market can't price in "prevents death." ## Taking MVPs to the Next Level - Tags: development, services, consulting Many people can build MVPs nowadays. What's harder is taking them to the next level. I offer a service where I deep-dive into your entire stack to figure out the best way forward for you or your team to continue developingwhile massively reducing your tech debt and ensuring basic compliance is adhered to at minimal cost. The goal isn't perfection. It's sustainable momentum. Let me help you bridge the gap between "it works on my machine" and "it's ready to scale." ## MVP to Production (the right way) - Tags: development, philosophy, mvp, ai MVP doesn't mean "bad code we'll fix later." It means: ship the smallest thing that proves the concept, but build it on foundations that won't collapse when you scale. AI has made building MVPs incredibly fast. You can prototype in hours what used to take weeks. But here's the thing: AI can also help you fix them quickly and take them to production level. I've seen too many startups build MVPs that become technical debt graveyards. They cut corners on architecture, skip database migrations, ignore auth best practices—then wonder why their Series A engineering team spends 6 months rebuilding everything. That's where I come in. AI allows me to deep-dive into your codebase, identify issues, and go that extra mile you hadn't thought of—turning your quick prototype into something production-ready, fast. My MVPs are production-ready from day one. Clean data models. Proper auth. Basic monitoring. API design that won't make future-you cry. Fast doesn't mean sloppy. It means knowing what actually matters. ## How do you work as an offshoring partner? - Tags: offshoring, remote, team, pricing I manage a remote team of talented developers who are cheaper than hiring locally—but I take full responsibility for everything they build. This isn't outsourcing where you send requirements over a wall and hope for the best. I'm your technical partner who happens to work with people across time zones. Here's how it works: - **I own the architecture** - System design, technical decisions, code reviews—that's all me - **I manage the team** - I hire, train, and oversee developers who execute on the plan - **I guarantee the quality** - If something's wrong, I fix it. You're not dealing with a faceless agency - **You get competitive pricing** - Lower rates because of where my team is located, high quality because I'm deeply involved I do most of my work remotely anyway. Async communication, clear documentation, regular check-ins. Whether my team is in the Netherlands or elsewhere doesn't change how we collaborate with you. You get me as your technical co-conspirator with the economic leverage of a distributed team. Best of both worlds: strategic leadership + efficient execution. ## How I work with offshore teams (without the friction) - Tags: offshoring, team, process, cost-efficiency I work with offshore developers sometimes. But here's the key difference from most offshoring setups: **You talk to me. I manage the team.** I have a trusted offshore team I've worked with before. I know their strengths, communication style, and how to get quality work out of them. When you work with me: - **No friction for you**: You don't manage offshore developers directly - **Single point of contact**: I translate requirements, handle communication, review all code - **Better prices**: You get cost efficiency without the coordination overhead - **Quality maintained**: I'm accountable for delivery, not some external PM This isn't "hire cheap devs and hope for the best." It's strategic offloading of implementation work while I maintain architecture, code quality, and client communication. You get the benefits of offshoring (lower cost, faster execution) without the typical headaches (timezone chaos, quality issues, miscommunication). ## PII Redaction: You Can Achieve More Than You Think - Tags: privacy, compliance, security You'd be surprised how much you can already achieve with PII redaction today. With modern tools and techniques, you can automatically detect and redact personally identifiable information from logs, databases, customer support tickets, and analyticswithout breaking your application flow. The tech is there. Pattern matching, ML-based detection, context-aware redaction. It's not perfect, but it's good enough to dramatically reduce your compliance risk and protect your users' privacy. Most companies just don't know it's possible, or think it's too complex. It's not. Start small: redact email addresses from logs. Then expand. Your legal team (and your users) will thank you. ## Regulation isn't anti-business, it's pro-sustainable business - Tags: regulation, compliance, markets Unregulated markets optimize for extraction, not value creation. When companies face no consequences for harvesting data without consent, deploying biased AI, or shipping unsafe devices, they race to the bottom. **The market doesn't self-correct** when users can't meaningfully consent or don't understand risks until it's too late. Strong compliance frameworks: - Build trust → users adopt new technology - Level playing fields → ethical companies aren't undercut - Prevent systemic failures → avoid Cambridge Analytica-scale disasters - Enable long-term thinking → invest in safety, not just speed Europe and Singapore understand: protecting users isn't anti-business. It's pro-*sustainable* business. Regulation isn't the enemy of innovation. It's the immune system of healthy markets. ## Regulatory sandboxes solve the chicken-and-egg problem - Tags: regulation, innovation, singapore You need real-world data to prove safety. But regulators won't let you deploy without safety proof. **Regulatory sandboxes solve this.** Singapore pioneered sandboxes for fintech, AI, and healthcare. Companies can test innovations under relaxed rules with regulatory supervision. This lets you gather evidence in controlled environments before full deployment. Why this matters: it enables innovation *within* guardrails rather than forcing companies to choose between compliance and experimentation. Europe is adopting this model too. It's the right balance. ## Why Singapore and Europe? - Tags: markets, compliance, philosophy Because they're the hardest markets to crack—and the most rewarding. Singapore has HSA medical device regulations and PDPA. Europe has GDPR, MDR, EU AI Act. Both have strict enforcement and zero tolerance for sloppiness. Most builders avoid these markets. Too complicated, too expensive, too risky. I specialize in them. If you can build for Singapore and Europe, you can build for anywhere. The compliance frameworks force you to think harder, build better, and create systems that actually respect users. Plus, these markets pay for quality. They want production-ready, auditable, defensible systems—not MVP duct tape. ## Why Singapore's HSA works - Tags: singapore, hsa, regulation Singapore's Health Sciences Authority (HSA) proves regulation doesn't require bureaucracy—it requires clarity. **What makes HSA work:** - Clear pathways for device approval - Risk-based classification (proportional scrutiny) - Fast-track routes for innovative tech (with evidence) - Predictable timelines if you have proper documentation HSA doesn't rubber-stamp approvals, but it doesn't create unnecessary delays either. I've worked with companies navigating HSA. The experience was transparent, rigorous, and efficient. You know what's required. You can't cut corners. If you do the work, approval happens. Singapore proves: smart regulation, not light regulation. ## What is your approach to technical architecture? - Tags: architecture, engineering, systems Good architecture is invisible. Bad architecture is everywhere. I design systems that solve the actual problem—not the trendy tech stack problem, not the "let's use this because I want to learn it" problem. The actual business problem. My architecture decisions optimize for: 1. **Maintainability** - Can someone else understand this in 6 months? 2. **Compliance** - Does this pass regulatory scrutiny? 3. **Scalability** - Will this handle 10x growth without a rewrite? 4. **Cost** - Are we burning money on infrastructure we don't need? I'm boring on purpose. PostgreSQL, not MongoDB (unless you actually need document storage). Django or Next.js, not the framework-of-the-week. Proven patterns, well-documented decisions. When I do choose something non-standard, there's a documented reason why. And when someone asks "why didn't we use X?", there's a clear answer. Architecture isn't about showing off. It's about building systems that work, scale, and don't surprise you with a midnight production incident. ## I only build projects that benefit the user - Tags: ethics, philosophy, projects I'm only interested in projects that benefit the user, not just the owner. This is a really important idea for me. If your product exists primarily to extract value from users rather than deliver value to them, I'm not interested. This means: - No dark patterns - No engagement manipulation - No business models where user benefit and company profit are at odds I want to build things where success for the business means success for the user. Aligned incentives. Mutual benefit. Everything else is just extraction dressed up as innovation.