Migrating a German 3D Printing Configurator Off Lovable Cloud and Rebuilding It for Production

Industry

Geography

Germany, Austria and Switzerland

Cooperation Period

8 to 10 weeks

About the Client

A DACH bureau competing on quotation speed

The Client runs a German additive manufacturing bureau that covers prototyping, small series, and short run industrial production across the DACH region. The bureau operates 5 printing processes and more than 80 materials, from polymer families like PA12 and PA11 through metal systems like AlSi10Mg, Ti6Al4V, and Inconel 718. Customers range from product teams uploading a single prototype to industrial buyers ordering repeating batches with purchase on invoice.

Before engaging Clixlogix, the Client already competed in a market where instant quotation was becoming the default expectation. Online configurators from larger European bureaus had reset buyer expectations away from the traditional email, PDF, and callback flow. The Client needed to meet that expectation without surrendering engineering quality or compliance discipline.

The platform Clixlogix inherited was a Lovable frontend with a Lovable Cloud backend, and the backend migrated to a Client owned Supabase account during the engagement. The scope covered an instant quotation configurator with DFM analysis, multilingual checkout, and B2B features. The engagement ran as an Audit plus Fix program on fixed cost, delivered through the Containment Method (Characterize, Contain, Convert), and the configurator is live in production, with discrete new scopes continuing.

Fig 1 - Prototyping to series production spectrum

The Challenge

The prototype did its job

The Client's path to the configurator was deliberate. A prior agency had been engaged on a different scope, as a prototype vendor, to validate the configurator concept on Lovable for the frontend and Lovable Cloud for the backend. That build demoed correctly and let the Client confirm the workflow, the material selection logic, and the customer flow end to end. The Client always planned to move to a production vendor once the prototype had earned its validation.

Four defects shaped the production brief

Pricing math drifted between runs - The same uploaded STL file returned different quotations on repeated attempts. The Client could not defend any single quote in writing.

The root cause was a chain, not a single bug:

Volume calculation ran client side through a sequence of parse, mesh repair, and triangle summation. When a non-manifold STL triggered the repair path, repaired geometry produced unreliable volumes, and the Client could not reconcile the differences across quote attempts.
For STEP files, the parser did not resolve the LENGTH_UNIT definition carried alongside the geometry's representation context. Interpretation ran on an assumed default that did not always match the file's actual unit system, so parts authored in inches came back priced as if they were millimeters, and vice versa.
Rounding and unit conversion flowed through several generated functions that each held their own assumptions.

Standards reference

The STEP format is published as ISO 10303 by the International Organization for Standardization. The LENGTH_UNIT entity lives inside the file's data section, referenced from the geometric representation context, and declares the unit system the geometry was authored in. A parser that does not resolve it reads dimensions in whatever unit it defaulted to.

Native CAD formats did not parse reliably - German industrial buyers upload STEP and IGES native CAD files, 3MF additive manufacturing meshes, and legacy STL. The prototype handled STL consistently and processed other formats unreliably, often without a visible error the operator could act on. Operators recovered failed or questionable uploads over email.

Design for manufacturability analysis was missing - Every file required an operator to open it in a desktop tool and check wall thickness, aspect ratio, and build volume by eye. The configurator advertised an instant quote while the back office carried hours of manual engineering review per working day.

B2B compliance paths were absent - VAT ID validation, EU reverse charge treatment, purchase on invoice, and separate billing and shipping addresses had no code paths. German commercial customers were falling out of the funnel at checkout.

The Client specified the review model

The Client also carried a specific architectural requirement into the Clixlogix engagement. The prototype vendor had used a two AI model approach inside their delivery, with one model generating code and a second model reviewing it. The Client had not been satisfied with that approach on the prototype work and asked Clixlogix for human engineering review on the production rebuild.

Fig 2 - Inherited architecture and defect clusters

Engagement Model

A 4 stage program

The engagement ran as an Audit plus Fix program on fixed cost, structured through a Scoping stage followed by 3 commercial phases that mapped to the Containment Method's Characterize, Contain, and Convert steps. The end to end envelope was 8 to 10 weeks across all four stages. Decisions on the Client side were held by the Founder, who approved every architectural choice directly, which kept decision latency to days.

Fig 3 - Containment Method gated program

Scoping

Scoping captured the engagement shape, confirmed access to the inherited codebase, aligned on the Client's human review requirement, and finalized the commercial scope for the three implementation phases.

Phase 1 - Inherited Codebase Audit

Phase one ran the Containment Method's Characterize step across the inherited Lovable frontend and Lovable Cloud backend. Static analysis and characterization tests mapped what the configurator did today, starting with the largest and riskiest files first. The audit completed in under 1 week, with a prioritized risk register the Client approved before any code changed.

Phase 2 - Pricing and Geometry Rebuild

Phase two ran the Containment Method's Contain step across the pricing, geometry parsing, and DFM analysis slices. Each slice stayed under 500 lines of change in motion at any one time. Everything outside the active slice stayed frozen, so the blast radius of any change stayed small and known. A pre-commit hook rejected any diff where a single changed file exceeded 500 lines, holding the ceiling in code, not in a documentation page.

Phase 3 - Checkout, Compliance, and Multilingual Rollout

Phase three ran the Containment Method's Convert step across B2B compliance, checkout, loyalty mechanics, PWA packaging, the Client admin interface for multilingual copy, and the multilingual rollout itself. The Clixlogix senior engineer reviewed every change inside each contained slice before merge, in line with the Client's explicit requirement for human engineering review. Decisions that could not reverse cheaply were locked into a constitution file holding domain rules, naming conventions, restricted code structures, and architecture rules under the technical lead's control.

Fixes deployed inside a modern platform pipeline, with reversible database migrations through the Supabase CLI running on every release.

Subsequent scopes continue as discrete engagements, with no open retainer.

Architecture Decisions

What stayed, what changed, what was built new

Component	Decision	Why
Backend platform	Migrated from `Lovable Cloud` to Client owned `Supabase`; retained Postgres, Auth, Storage, and Edge Functions after migration	Preserved customer records and established Client ownership of the production data environment
Lovable frontend	Kept about half (upload, viewer, cart); rebuilt the configurator	Single purpose components survived; orchestration got rewritten
Backend language	Rewrote to `FastAPI` plus `Celery` plus `Redis`	Python is the native home for CAD and numerical libraries
Native CAD parsing	Introduced `OCCT` via `pythonOCC` plus `CAD Exchanger` fallback for unsupported cases	B-Rep topology enables defensible DFM analysis
Pricing	Rewrote as a hybrid rules engine (Supabase tables plus Python formulas)	Every quote resolves through the same auditable path
DFM analysis	Server side with file hash caching	Compute once per unique file

Table 1 - Architecture decisions at a glance.

Engineering specifics (worker limits, OCCT APIs, deflection tolerances, GLB encoding) sit in Table 4 at the end of the case study.

The decisions in detail

The backend moved to Client owned Supabase and retained all four Supabase services - The existing Postgres structure and data moved intact without a schema redesign. Postgres, Auth, Storage, and Edge Functions then operated from the Client's account. The migration preserved customer records, authenticated sessions, stored CAD files, row level security policies, and Edge Function behavior. It also gave the new FastAPI backend direct database access and established Supabase CLI migrations as the production change process.

About half the Lovable frontend survived into production - The upload component, the 3D viewer wrapper, and the cart earned reuse because each did one thing with a bounded dependency surface. Clixlogix kept them under version control with explicit state management added around them. The configurator stepwise flow was rebuilt in full because it had to orchestrate the new pricing engine, DFM analysis API, and compatibility logic across multiple backend calls.

AI generated code survives review when it does one thing. It gets rewritten when it has to orchestrate.

Python became the backend language, with Celery and Redis as the task queue - The pricing engine, geometry parsing, and DFM analysis moved to a FastAPI service, with Celery handling asynchronous CAD parsing and analysis jobs on Redis. CAD parsing jobs run in isolated Celery child processes under the process based (prefork) pool, with task recycling and resource limits that give native crash isolation from the C++ wrapped CAD kernel. The configuration reduces the impact of parser crashes and memory growth on the queue, without claiming the semantics of a security sandbox. The alternative, keeping all backend logic inside Supabase edge functions, would have forced reimplementation of mature geometry libraries in TypeScript and offered no process isolation for a C extension that can segfault.

Native CAD parsing moved to OCCT or CAD Exchanger with B-Rep metadata extraction - The CAD worker uses OCCT (via pythonOCC) as the primary kernel for STEP and IGES, with CAD Exchanger as fallback for unsupported native CAD cases where the primary kernel does not produce a usable result. The parser extracts B-Rep metadata, calculates volume and DFM rules against the B-Rep solid, and tessellates geometry for the browser. Mesh formats like STL, OBJ, 3MF, and PLY are handled by trimesh with mesh analysis by Open3D. The alternative, relying on mesh conversion before any geometry work, would have discarded the native CAD topology that B-Rep based DFM analysis depends on.

Pricing moved from AI generated code to an explicit rules engine with Client control - Clixlogix rewrote pricing as a hybrid engine. Cost tables, per technology, per material, per finishing, live in Supabase as Client editable runtime configuration with version history and effective dates on every row. The Python engine in FastAPI reads the active version at quote time and applies formulas against those tables. Saved quotes retain the rule version in effect when the quote was issued, so a historical quote always resolves to the same number it did on issue. Introducing a new material or finishing type is additive configuration, not a code deployment, except where it needs a new schema column. The alternative, continuing to let generated code produce quotes, left no path for the Client to defend a price in a commercial dispute.

DFM analysis runs server side and caches by a compound key - Each uploaded file is hashed on arrival. Geometry analysis and DFM output are cached by a compound key of file hash plus analysis engine version, DFM threshold version, process and material selection, and any unit override or repair settings applied. Results are reused only when every input dimension matches. Cache entries are scoped per tenant, so cross customer deduplication cannot expose another customer's file, signed URL, or stored artifact. The alternative, running the analysis again on every page interaction, would have driven infrastructure cost up and latency unpredictably.

The Solution

Fig 4 - Production system architecture

Lovable Cloud to Client owned Supabase Migration

Lovable Cloud gave the prior agency a fast route to a functioning backend. It supplied the database, authentication, file storage, and Edge Functions needed to validate the configurator workflow inside the Lovable environment. This helped the Client confirm the quotation journey, material selection logic, customer accounts, and order flow before committing to production development.

The configurator had become responsible for commercially important information by the start of the Clixlogix engagement. It held customer records, uploaded CAD files, pricing configuration, quotations, and order data. The Client required direct ownership of the account that stored and processed this information.

Clixlogix made the migration from Lovable Cloud to a Client owned Supabase account the first operational step of the engagement. Clixlogix preserved the existing Postgres structure and production data during the transfer. The migration moved control of the database, authentication settings, storage, Edge Functions, credentials, billing, and project configuration into the Client's account.

The migration preserved:

Postgres schema, customer records, tables, columns, constraints, and row level security policies
Supabase Auth configuration, user accounts, and active sessions
Uploaded CAD files in Supabase Storage
Edge Functions registered by the prior build

The Client gained direct access to the Supabase dashboard and could manage team permissions, production credentials, usage, billing, backups, compute settings, and future engineering access. Database changes moved into versioned Supabase CLI migrations managed through the Client's development process.

The Client owned account also provided controlled database access for the new FastAPI services. Pricing, CAD processing, and DFM analysis could read and write the required production data through credentials governed by the Client.

The cutover used a point in time copy during a 24 hour weekend maintenance window. Data reconciliation confirmed that every customer record transferred successfully. Existing authenticated sessions continued, and uploaded CAD files remained available.

The migration established a production environment owned by the Client. Future engineers and service providers can receive access through the Client's Supabase organization, while the Client retains authority over its customer information, operating costs, security settings, and deployment decisions.

CAD File Ingestion and Format Support

The configurator accepts 12 CAD and mesh formats programmatically, up to 100 MB. The public upload surface prominently presents the five most common formats (STL, STEP, 3MF, OBJ, IGES) and accepts the remaining formats through file extension and MIME detection for buyers who need them.

Mesh formats - STL, OBJ, 3MF, PLY, WRL, DAE, 3DS, X3D
Native CAD formats - STEP, STP, IGES, IGS

The frontend uses the TUS resumable upload protocol to stream the full CAD payload directly to Supabase Storage, with chunked retry on network interruption, bypassing the application backend entirely. Upload URLs are short lived and signed. MIME type and extension are validated against the accepted list before parsing is enqueued, file size is enforced server side, and incoming payloads are scanned for known malware signatures.

Why This Matters

Streaming a 100 MB CAD file through a serverless function or an HTTP proxy would cause timeouts and memory bottlenecks. Direct client to storage transfer sidesteps the problem.

On upload completion, a Supabase Storage webhook notifies the FastAPI service, which deduplicates the file by content hash and enqueues a Celery job on Redis. Both native CAD files and mesh files run asynchronously through the queue, so large meshes do not block the API thread. The Client's historical fallback, operator review by email, remains available only when a file fails automated parsing.

Geometry and DFM Analysis Engine

Fig 5 - CAD processing pipeline

The analysis engine returns:

Model dimensions, volume, surface area
Estimated wall thickness and minimum required wall thickness
Weight by material
Aspect ratio assessment
Build volume compatibility against each configured process
Manufacturability risks and process specific design recommendations

Volume calculation on the B-Rep solid - For native CAD files, OCCT via pythonOCC parses the geometry as the primary kernel, with CAD Exchanger as fallback for proprietary formats. Volume is calculated directly against the B-Rep solid with explicit resolution of the file's declared unit system, so unit interpretation is deterministic across every submission. The B-Rep approach replaced the inherited build's client side chain of parse, mesh repair, and triangle summation, which was the real root cause of pricing drift when non-manifold input hit the repair path.

Multi body and assembly handling - For files that contain multiple bodies, including nested sub assemblies common in industrial STEP and IGES uploads, the OCCT worker enumerates the discrete solids present in the file. STEP assemblies carry transformation data on each component; the worker preserves component placement so composite bounding envelopes reflect the assembled layout. IGES files that arrive as loose surfaces run through a sewing step before solid enumeration; files that still do not yield closed solids route to manual engineering review. Composite bounding envelopes are calculated for assemblies that print as one unit, and files that need individual body treatment flag an engineering review step before the quote renders. The split decision between "one printable part" and "assembly needing separation" is held by the operator, not by the automation.

Tessellation for browser rendering - Native CAD geometry is tessellated with controlled deflection tolerances so the output glTF or GLB stays within a size budget suitable for in browser preview. The Three.js viewer renders typical industrial STEP uploads with clean visual curvature on current desktop and mobile browsers.

Standards reference

The glTF format used for browser side 3D rendering is maintained as an open standard by The Khronos Group, the industry consortium behind Vulkan, OpenGL, and OpenCL.

Wall thickness heatmap - For files where wall thickness is the deciding factor on printability, the engine produces a wall thickness heatmap. The algorithm samples points across the mesh surface and casts rays inward along surface normals, using Open3D's ray intersection queries to measure the distance from each sample point to the opposite surface. The sampler handles open meshes and self intersections with confidence thresholds, so low confidence regions are flagged for review and do not surface in the heatmap as false thin walls. Scalar thickness values are mapped to an RGB gradient and baked into the exported geometry as per vertex color, so the Three.js material renders the heatmap without a secondary texture download.

Fig 6 - DFM wall thickness heatmap

Compatibility Aware Configurator Flow

The configurator presents choices in the order:

Technology
Material
Finishing
Color
Quantity

Each step filters the next by compatibility inside the configurator UI, so an invalid combination is prevented in the interface. A single authoritative compatibility matrix drives both the UI filter and a server side validator that runs on quote submission, so a stale client cannot submit an incompatible configuration. The entry state is derived from the uploaded model, so a customer uploading a part that fits only one build volume sees that filter applied automatically.

Pricing Engine

Pricing is calculated against provider backed cost tables and renders in real time as the configuration changes. Unit price and total price are calculated per configuration against the Client's commercial rules recorded in the cost tables, which cover quantity support, tier pricing, minimum quantities, and process specific caps. Saved quotes retain the rule version in effect at issue time, and quote expiry is set per the Client's commercial policy. Production lead time and expected shipping date are calculated from the material, process, and finishing combination. Minimum order surcharge and free shipping threshold are evaluated at cart level across mixed process baskets, with VAT handled through the Stripe Tax integration described below.

Checkout, Payments, and B2B Compliance

Checkout supports six payment paths:

Credit and debit cards
Apple Pay
Google Pay
PayPal
Bank transfer
Purchase on invoice for verified business customers

All payment methods route through the Stripe surface so the Client holds a single payment vendor relationship. Cards, Apple Pay, Google Pay, and PayPal settle through Stripe's unified payment flow, with PayPal integrated as a Stripe Alternative Payment Method (not through Stripe Connect). Bank transfer and purchase on invoice run through Stripe's business customer path, with invoice eligibility decided by the Client's own credit rules applied through a verification flag the configurator reads on the customer record.

Stripe Tax applies EU reverse charge treatment and performs asynchronous VAT ID validation inside the Stripe checkout flow, so the pricing engine does not carry its own tax calculation code. Customer information accuracy, as Stripe documents, remains the Client's responsibility, and the Client's operations surface the validation state back to the operator when follow up is needed.

Industry context

The EU reverse charge mechanism for VAT on cross border B2B transactions is documented in the EU VAT rules on the European Commission's taxation portal. VAT ID validation runs asynchronously through the EU VIES service, and the merchant retains responsibility for buyer information accuracy under EU rules.

The B2B path includes separate billing and shipping addresses, optional purchase order PDF upload, reseller and loyalty program handling, and DHL shipment notifications. Purchase order PDF uploads are gated by file type and size validation, scanned for known malware signatures, stored under the same per tenant access controls as CAD uploads, and retained under the Client's documented records policy. Orders that cannot be priced instantly fall back to a manual quotation workflow that preserves the configuration and the uploaded file.

Fig 7 - B2B checkout concept

Multilingual Admin Interface for Client Copy

Copy for all 4 language locales (German, English, Spanish, French) lives in a Supabase table of locale keys. Clixlogix built an admin interface on top of that table so the Client manages copy without a code deploy. Locale changes carry version history, with the admin interface showing a preview against the live configurator before publication so the Client can review changes in context.

Accounts, Saved Configurations, and Cart

Customers can calculate 5 quotations as guests, with the count enforced server side against the authenticated session identifier so the limit holds across browser clears and incognito sessions. Registered customers move to unlimited calculations with per account rate limits to contain abuse. Registered customers save configurations for later use and manage profiles and past orders. The cart supports multiple configured parts in one order.

PWA Shell

The configurator is installable as a Progressive Web App with service worker support. The service worker caches static shell assets only. Customer CAD files, signed Supabase URLs, quotes, checkout pages, and authenticated API responses never enter the cache. Service worker updates ship a cache busting version marker on every release, so stale pricing or configurator code cannot persist in a client that was installed a day earlier. Operators inside the Client's bureau install it as an internal tool for intake and review alongside their customer facing deployment.

Where It Struggled

The Characterize step surfaced several defects inherited from the prototype build.

Defect surfaced in Characterize	How Contain and Convert resolved it	Why it mattered
AI generated pricing code produced different quotations on repeated runs for the same file	The rewrite defined pricing invariants and historical quote scenarios first, with tests derived from the Client's past orders. The senior engineer reviewed every change inside the pricing slice before merge, in line with the Client's requirement for human engineering review	Pricing could be verified against real production outcomes before any customer saw it
Native CAD formats fell back to error pages without a visible error	AI defaulted to generic error handling. The technical lead's domain knowledge replaced it with CAD standard aware handling for missing header definitions, truncated streams, IGES section divider validation, mismatched Directory to Parameter pointers, and unsupported entities within `AP203`, `AP214`, and `AP242` files that `OCCT` could not interpret	The Client's actual customer file mix drove the geometry library choice and the error handling depth
DFM thresholds were per process constants hardcoded in prototype code	DFM parameter values moved to versioned Supabase configuration the Client controls, with audit trail. Schema definitions live in database migrations. The constitution file in the codebase prohibits hardcoded thresholds, so later generations route to the configuration surface instead	The Client can adjust thresholds as process capability improves without an engineering ticket
Payment paths were partly implemented and partly stubbed	Payment work consolidated behind Stripe's unified payment flow, with each path treated as a stateful decision inside its own contained slice. The slice ceiling kept the payment code under 500 lines in motion at any time	Partial payment paths are a direct revenue risk
Checkout VAT handling assumed consumer customers	VAT ID validation and reverse charge logic moved to `Stripe Tax` wired into Stripe's unified payment flow, inside a dedicated Convert slice	German commercial customers represent a defined share of the Client's revenue

Table 2 - Defects surfaced and how the Contain and Convert steps resolved each one.

Results

The engagement delivered a production hardened platform in 8 to 10 weeks, eliminating the need for a 6 to 12 month total rebuild. The configurator preserved the Client's validated workflows and their existing customer accounts, with every path a customer or an auditor would follow rebuilt underneath.

500+ Reviews on Trustpilot

Trustpilot aggregates post launch customer feedback on the live configurator under the Client's verified profile. The accumulated volume gives new buyers independent social proof at the moment they review their quote.

2x+ Orders Per Week

Order volume against the prior email funnel baseline. Instant quoting captures demand that previously left the funnel waiting for a sales engineer to respond, and converts browsing buyers inside a single session.

1-2h Daily Savings

Per operator time recovered each working day from manual DFM review. Automation runs wall thickness, aspect ratio, and build volume checks on upload, so operators handle exception files only.

8-10wk Delivery

End to end engagement envelope from Scoping to live production. The compressed window eliminated the need for a 6 to 12 month total rebuild and preserved validated workflows and existing customer accounts.

Seconds to Quote

Standard quotation time inside the configurator, against the prior email and wait baseline that ran hours to days. Buyers configure, price, and order a part inside a single uninterrupted session.

4 Locales Shipped

German, English, Spanish, and French language coverage from day one. Copy for every locale is Client managed through a dedicated admin interface, so new markets and campaigns ship without an engineering ticket.

What the Client Does Differently Now

DFM review is automated - Operators no longer open every uploaded file in a desktop CAD tool to check wall thickness, aspect ratio, and build volume. The automated DFM engine returns those results on upload, and the operator role moves to exception handling for files the automation flags.
Pricing updates ship through Client self service - Cost adjustments, new materials, and new finishing options land as versioned configuration updates with effective dates, applied through the admin interface without a code deployment. Changes to the formula logic itself, or to compatibility rules that affect the matrix, still ship as a code release so the technical lead holds the review gate on anything that touches the pricing math.
The B2B funnel closes commercial orders inside the configurator - The B2B funnel supports VAT ID validation, EU reverse charge, purchase on invoice for verified business customers, and purchase order PDF attachments. The Client processes commercial orders through the configurator that previously required a sales engineer to complete offline.
Copy ships without an engineering ticket - The Client manages copy in all 4 language locales through an admin interface Clixlogix built on top of the Supabase locale table. New campaigns and locale corrections ship without an engineering ticket, with Client managed copy editable directly.
The product doubles as an internal operator tool - The entire product is installable as a PWA. Internal operators run it as a desktop grade tool for intake and review alongside the customer facing deployment.

Consulting Insight

Consulting insight

The Client specified human engineering review before Clixlogix proposed a method. A Client who has lived through one AI build is the strongest person to write the specification for the next one.

The Containment Method applied that specification by sorting the inherited code into two kinds. Pricing, geometry parsing, and DFM analysis are math and were rewritten under explicit invariants. Upload, viewer, and cart components are glue and were kept with state discipline added around them.

The 500 line slice ceiling held each piece of that work. The pre-commit hook rejected PRs when a diff crossed the line. Discipline that lives only in a documentation page is not discipline.

Technologies and Tools

Area	Technology
Frontend framework	`React`, `TypeScript`
Frontend starting point	About half the components inherited from `Lovable`, taken under version control. Configurator rebuilt
Source backend platform	`Lovable Cloud`, using Supabase services
3D viewer	`Three.js`, rendering `glTF` and `GLB` tessellation output
Backend service	`FastAPI`, `Python`
Task queue	`Celery` on `Redis` as broker and result backend for asynchronous CAD parsing and analysis
Native CAD kernel (primary)	`OCCT` via `pythonOCC` for `STEP` and `IGES` with B-Rep metadata extraction
Native CAD kernel (fallback)	`CAD Exchanger` for unsupported native CAD cases where the primary kernel does not produce a usable result
Mesh and geometry analysis	`trimesh` for mesh formats, `Open3D` for mesh analysis including wall thickness
Production data platform	Client owned `Supabase` account with `PostgreSQL`, Auth, Storage, and Edge Functions
Pricing engine	Hybrid, cost tables in Supabase and Python formulas in FastAPI
Payments	`Stripe` surface across all six payment paths. Cards, Apple Pay, Google Pay, and PayPal through Stripe's unified payment flow (PayPal as a Stripe Alternative Payment Method). Bank transfer and purchase on invoice through Stripe's business customer invoicing path for verified B2B accounts
Tax compliance	`Stripe Tax` applying EU reverse charge and asynchronous VAT ID validation inside the Stripe checkout flow
Shipping notifications	`DHL` shipment tracking integration
Progressive web app	Service worker, Web App Manifest
Deployment pipeline	`Vercel` CI/CD for frontend rapid iteration
Database migrations	`Supabase CLI` managed migrations with explicit down migrations where a change is reversible; destructive changes ship with compensating migrations, with no reliance on auto rollback
Hosting posture	Dockerized FastAPI and Celery workers deployed on EU hosted AWS ECS
Delivery method	Clixlogix Containment Method (Characterize, Contain, Convert), run under the Vibe Code Rescue program
Review discipline	Senior engineer reviewed every change inside each contained slice before merge
Slice ceiling enforcement	`pre-commit` hook rejects any diff where a single changed file exceeds 500 lines
Constitution file	Domain rules, naming conventions, restricted code structures, and architecture rules, controlled by the technical lead
Agentic development environment	Clixlogix agentic workspace with `Zoho Projects`, `GitHub`, and research `MCP` servers wired to the build environment. The data boundary is explicit: customer CAD files, personal data, and production secrets never route through the research `MCP` surface, which operates on sanitized fixtures and anonymized schema only

Table 3 - Technology inventory across frontend, backend, data, payments, and delivery discipline.

Engineering Specifics

Engineering level implementation details for a technical reader. Business readers can safely skip this section.

Area	Specific implementation
CAD volume calculation	`BRepGProp::VolumeProperties` on the B-Rep solid with explicit resolution of the `LENGTH_UNIT` definition from the file's data section
Multi body assembly handling	`TopExp_Explorer` traversal with `TopAbs_SOLID` filter to enumerate individual solids
Browser tessellation	`BRepMesh_IncrementalMesh` with chordal deflection tolerances of approximately 0.05 mm linear and 0.5 radians angular, GLB output bounded under 15 MB
Wall thickness ray queries	`Open3D` RaycastingScene, which carries its own internal acceleration structure for mesh ray queries
Heatmap encoding	Scalar thickness values baked into the `COLOR_0` vertex attribute buffer of the exported GLB, rendered through `Three.js` PBR material at 60 FPS, no secondary texture download
STEP schema coverage	`OCCT` handles `AP203`, `AP214`, and `AP242` schemas; unsupported schema entities route to the `CAD Exchanger` fallback
CAD worker process isolation	`Celery` prefork pool with `--max-tasks-per-child=10` task recycling, hard and soft time limits around 120 seconds per task, and per worker memory limits. Child processes contain native kernel crashes and bound memory growth; this is process containment, not a security sandbox
Upload transport	`TUS` resumable upload protocol direct to Supabase Storage, chunked retry on network interruption

Table 4 - Engineering specifics for the deployed system.

Services Delivered

Vibe Code Cleanup, Inherited Codebase Audit, Python and FastAPI Backend Development, React and TypeScript Frontend Development, AWS Hosting and Deployment, DevOps and Release Pipeline, Project Rescue, CAD Geometry and DFM Automation, Stripe Payments and EU Tax Compliance

Team Composition

Technology Lead, Senior Engineer, Backend and CAD Engineers, Frontend Engineer, Project Manager

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

Guarded Delivery around a vibe coded product

Taking a Vibe Coded US GLP-1 Prototype to Production

Mobile App Development Digital Engineering Devops Consulting Service Healthcare & Life Sciences

Dating Profile AI App Cleared App Store on First Submission and Hit the Valentine’s Day Window in 8 Weeks

Digital Engineering Consulting Service AI Emerging Tech

View All Vibe Coding Cleanup Case Studies