Compliance software developer · GoBD + GDPR (Bubble.io + Claude Code)

Compliance software development is the discipline of building production SaaS under a regulated framework (GoBD, GDPR, HIPAA, SOC2, audit-required jurisdictions) where schema choices, audit-log integrity, RLS policies, role boundaries, and consent surfaces are designed in from day one. The work is not a checklist run at the end of a build. It is the shape of the schema, the structure of the workflows, the discipline in the change log. The product that survives the first audit is the product that was built with the audit in mind from the first commit.

Most compliance work I see arrives late. The product ships, the first regulated customer signs, the auditor walks in, and the team discovers their data model cannot answer the question “show me every change to this field with the actor and the timestamp.” Then the rebuild starts. The rebuild is more expensive than the original build. The version that ships compliant from day one is cheaper, faster to audit, and faster to extend. That is the version this page is about.

What compliance-aware development means

Compliance-aware development is a small set of structural disciplines that hold across frameworks. The framework decides which fields are sensitive, which retention periods apply, which consent surfaces the user sees, which export format the auditor accepts. The engineering discipline underneath is the same.

Schema-first design. The shape of the database decides whether the audit-log question can be answered cheaply or at all. A field that needs to be tracked, versioned, or compared between two states has to be a first-class data type, not a hidden subfield of something else. Three weeks on the schema saves months of rewrite.

Audit-log integrity. Every change to a sensitive field writes a row with the previous value, the current value, the actor, and the timestamp. The log is the substrate the auditor reads. The log is also the substrate the GDPR right-to-erasure workflow has to preserve: deletion writes a tombstone with the actor scrubbed but the value-change retained, so both the GoBD Unveränderbarkeit posture and the GDPR deletion posture survive.

RLS per tenant. In a multi-tenant SaaS, the tenant boundary lives at the data type level, not in a UI filter. Privacy Rules on Bubble.io, Row Level Security on Postgres (Preferably Supabase), the same idea on either stack. A tenant boundary in Conditional Visibility is one missed check from a cross-tenant leak. A tenant boundary on the data type holds whether the request comes from the UI, the API, or a future client.

Immutability where the framework demands it. GoBD calls it Unveränderbarkeit: once a field is written, the prior value cannot be silently overwritten. The previous value is preserved in the audit log; the new value is its own row. The schema, the workflow, and the deletion semantics all conspire to enforce this.

Consent and data-minimisation surfaces. GDPR specifically: lawful basis declared per processing activity in the data model, consent captured at the point of use, data minimisation applied at form design, right-to-erasure preserved through the audit log integrity. The consent surface is not a cookie banner. It is the structural commitment the schema records.

Regulatory-language drafting. The hardest part of filling in a compliance form is the language. A small-business owner knows what they do; they do not know how to phrase it in compliance-officer-speak. First-draft assistance from an LLM (OpenAI, Anthropic) accepts a plain-language answer and writes the compliance-specific paragraph for the user to review and save. The AI is a first-draft assistant; the user owns the final wording. The audit log records who saved what, not who drafted it.

How the build runs

The pattern is the same across regulated frameworks. Four phases, run in order, with a human gate between each.

The first two weeks, at minimum, is reading. Which framework applies (GoBD, GDPR, HIPAA, SOC2, sector-specific). Which fields are sensitive in this product. Which retention windows attach. Which export format the auditor expects. Which consent surfaces the user must see. What the failure mode looks like on the day of the audit. Compliance understanding is not a one-week job; the brief that lands at the build phase has to be precise enough that the schema decisions write themselves.

The schema is where compliance lives or dies. Tenant has Companies. Company has Users. User has Roles, scoped per Company. Each sensitive field gets its own audit-row history. RLS policies at the data type level. Immutability written into the change-tracking machinery so the prior value survives every edit. Role boundaries declared in data, not in UI filters. The dashboard, the forms, the export surface all read from this foundation.

Forms are built from the schema and every save goes through the compliance workflow. A per-field change log records the previous value, current value, actor, and timestamp at the exact granularity an auditor needs. An AI drafting tool helps users write compliance-specific language from plain answers; the user reviews, approves, and the audit log records what they saved. Critical changes notify the right roles immediately; minor edits batch into a digest so nobody gets flooded with alerts.

Production deployment with the safety hooks added before the first user, not after the first audit. Monitoring connected so silent failures surface. The export surface produces auditor-readable formats on demand. The architecture is designed to accept the next framework refresh (the BMF letter, the next GDPR clarification, the next sector ruling) as a configuration change, not a rewrite. The retainer that follows handles the refresh, the ongoing audit support, and the feature work the next milestone needs.

A real compliance build, shipped, with the receipts.

Compliance · GoBD + GDPR

German Compliance Software: Requirement → MVP → White-label SaaS

Multi-tenant SaaS for GoBD-compliant Verfahrensdokumentation. All seven GoBD principles structural. April 2024 BMF revision in force from day one. GDPR on top: consent, right-to-erasure, Article 28, EU-region data pinning. Live since 2024.

V1 V2 V3 In production
GoBD + GDPR Frameworks
2024 Live since

Read the case study →

Honest scope

What I have shipped, and what I will not claim to have shipped.

Lived experience: GoBD V1 V2 V3 (German bookkeeping rules under the BMF April 2024 revision, live since 2024 across two production milestones, V3 in development) and GDPR (consent surfaces, data minimisation, lawful-basis-per-processing-activity, right-to-erasure preserved through audit-log tombstones, Article 28 processor agreement, EU-region data pinning). Both shipped on the same Bubble.io application, both audited as part of the live product.

Engineering transfer: HIPAA, SOC2, FINRA, and other regulated frameworks share the same underlying disciplines (schema-first design, audit-log integrity, RLS per tenant, immutability, role boundaries, consent surfaces). I have shipped those disciplines in production under GoBD and GDPR. I have not shipped a HIPAA-certified or SOC2-certified product specifically. The engineering pattern transfers; the framework-specific specialist knowledge has to be paired with a compliance attorney or framework-certified consultant on your side.

I will tell you on the call whether your framework is one I can serve directly, one I can serve with framework-specific advisory paired alongside, or one you should hire a framework-certified specialist for instead. The honest answer is part of the discovery, not after it.

Engagement terms

Same as the rest of my practice. Hourly only. $60 per hour. Tracked via Upwork or similar; weekly invoices; no setup fee, no padding. Minimum is a few hours of scoping discovery; no commitment beyond that until you are confident. Compliance builds typically run six to sixteen weeks for the V1 production-shaped product, with a retainer for ongoing audit support and the next milestone.

Send your spec, your framework, and your timeline when you book the call. I will tell you whether the build is one I should lead directly, one I should lead with framework-specific advisory paired alongside, or one you should hire a specialist for instead. The decision happens once, with you in the loop.

Before the call

Common questions.

What regulated frameworks have you shipped work in?

GoBD V1, V2, and V3 (the German tax authority's rules for digital books and records under the BMF April 2024 revision, live since 2024 across two production milestones with V3 in development in 2026) and GDPR (consent surfaces, data minimisation, lawful basis per processing activity, right-to-erasure preserved through audit-log tombstones, Article 28 processor agreement, EU-region data pinning). Both shipped on the same Bubble.io application. The product is live at app.verfahrensdokumentation-digital.de and the case study is at the GoBD case study.

Do you specialize in HIPAA or SOC2 specifically?

Not directly. My lived experience is GoBD and GDPR. The underlying engineering disciplines (schema-first design, audit-log integrity, RLS per tenant, immutability, role boundaries, consent surfaces) transfer to HIPAA, SOC2, FINRA, and other regulated frameworks. I will tell you on the call whether your framework is one I can serve directly, one I can serve with a framework-certified consultant paired alongside, or one you should hire a specialist for instead. The honest answer is part of the discovery.

What does a compliance-aware build look like versus a normal SaaS build?

The difference is invisible in the demo but shows up the day of the audit. In a normal SaaS build, data is stored and displayed. In a compliance-aware build, every change to a sensitive field is recorded: what changed, who changed it, and when. Access is controlled at the database level, not in a UI filter, so there is no way to accidentally expose the wrong data to the wrong user. Once something is written, it cannot be silently overwritten. And the product can export a full audit trail on demand. None of this is visible in a demo. All of it is what keeps the product standing when the auditor walks in.

How long does GDPR or compliance integration take on a new SaaS?

On a new build, integrating compliance from day one adds about forty percent to the V1 timeline. The added cost is mostly in the schema and the audit log; once those are in place, the rest of the build runs at normal speed. The savings come later: no rebuild after the first audit, no schema rewrite to surface compliance data, no retrofit of the consent and erasure surfaces.

Can you retrofit GDPR consent and audit logs into an existing SaaS?

Yes, usually. The retrofit timeline depends on how the existing schema is shaped. A clean data model makes it straightforward: consent surface, audit log on the sensitive fields, right-to-erasure workflow, lawful-basis tagging. A schema-tangled product takes significantly more work; sometimes the honest answer is a rewrite. I will tell you which on the call after reading the spec and the schema.

Will you stay on for ongoing audit support and GDPR refresh?

Yes. Most compliance engagements continue beyond the initial build as ongoing work: audit-window support, regulatory-refresh integration (new BMF letters, new GDPR clarifications, new sector guidance), and the next milestone of feature work. Same $60/hr rate, no minimum. It means 'the auditor is here next month' and 'the regulator just published a clarification' are handled without standing up a separate engagement each time.