c-84, sector 65, Noida
c-84, sector 65, Noida
An AI floor plan SaaS had proven its product on a regional cloud proof of concept but could not carry a paying global user base. Clixlogix rebuilt it as a production platform, migrated it to AWS with a routed OpenAI portfolio across 6 models, and cut over millions of users without downtime or a credit ledger discrepancy.

The client operates an AI first floor plan and interior design platform. The product covers the arc from a text prompt to a CAD ready export. A user might type “open plan 2 bedroom apartment with a north facing kitchen” and reach an editable floor plan in seconds, then work through the 2D editor and 3D viewer before generating a photoreal interior render and exporting a DXF that opens cleanly in AutoCAD. Its user base spans residential and commercial design work, from a homeowner planning a renovation to an interior designer presenting layout options to a client. Registered users number in the millions across global markets, and the paying subscriber base has grown through multiple product phases without a break in service.
The engagement began when the client had a working proof of concept on Qwen models hosted on Alibaba Cloud that had validated the core value proposition, an AI generated floor plan from a natural language prompt. Clixlogix took ownership of the production build from that point onward. The current engagement covers 3 pieces.

Fig 1 – Three engagement phases, with the computer vision mobile companion still in progress.
The client’s proof of concept had proven the product idea. It had not proven that the same architecture could support a production paid platform at global scale, and it was never designed to.
The gap between a proof of concept and a production floor plan platform is wider than it looks, and every element of that gap has a revenue consequence.
A production paid platform cannot afford any of these shortcuts once real users depend on the product for real work. Every unaddressed shortcut lands somewhere on the ladder from support ticket through chargeback to churn. The commercial cost of an unstable AI product shows up as the enterprise deal that never closes because the security page is thin. A single lost deal costs more than a year of direct refunds combined.
2 forces on top of that gap shaped the technical brief.
North American and European users grew into the largest revenue cohorts, and the round trip from those regions to Alibaba Cloud added measurable latency on every generation. In a product where a user often triggers 5 or 6 generations in a single working session, that latency compounds into a real drop in per session engagement. Enterprise procurement conversations kept surfacing objections about data residency and compliance posture that the regional cloud provider could not answer for US and EU customers. A global product needed a global cloud footprint, and the deals waiting on the answer to that question were meaningful.
A prompt for a simple room rename used the same model as a from scratch 3 bedroom layout, and both used the same model as a hard constraint solver for a commercial layout with fire egress rules. Structured outputs required extensive post processing before the layout engine could read them. Vision understanding on uploaded sketches and PDFs left gaps that surfaced as broken geometry. Every generation carried an implicit model cost that no one was routing against actual request difficulty.
Alongside these production forces, the client identified a further usability constraint. Drawing a floor plan in a browser, even a well designed one, asks a lot of a user. That observation shaped the current phase of work, a mobile companion that turns a walkthrough of a real room into an editable floor plan without a drawing step. The addressable market for a product that requires walking through a room is much larger than for a product that requires drawing one.
The engagement therefore had 3 anchor goals.
All 3 goals had to hold without breaking the paying subscriber base and without disturbing the credit ledger that governs their entitlement.
Clixlogix ran the engagement in phases so that each workstream could ship independently without freezing the product roadmap. Clixlogix built and shipped the production web shell first. The cloud and model migration ran on top of that stable foundation. The mobile companion remains under active development in parallel with continued web platform work. The sequencing was deliberate. Migrating a production platform is much easier when the platform is already production hardened.
Clixlogix inherited a proof of concept codebase that had validated market fit and rebuilt it as a paid platform that could survive real user volume and real revenue pressure.
Clixlogix rebuilt the frontend on Nuxt 3 with Vue 3 as the underlying framework and Tailwind CSS for styling. Vue Query handles server state and API cache invalidation. The 2D editing surface runs on a Canvas and SVG hybrid that gives pixel accurate rendering for large plans and vector output for exports.
Clixlogix rebuilt the backend on NestJS with a service oriented module structure. Every route returns a uniform response envelope, which lets the frontend handle every response through the same pipeline and lets errors carry a consistent shape across the surface. Cross cutting concerns run as global NestJS middleware, so no controller has to duplicate that behaviour and no controller can accidentally skip it. That discipline is what keeps engineering velocity high once the product has more than a handful of endpoints.
Persistence moved to PostgreSQL with a formalized schema. Redis handles session state and ephemeral generation state, with the same footprint backing the job queue. The change from an informal proof of concept schema to a formal one was the single most important decision of the web shell phase. Every downstream capability depends on a stable data model underneath.
The production web shell shipped on the original regional cloud footprint before migration began. Migrating a paid platform is a business risk event. Doing it after the platform is stable is much safer than doing it while the platform is still forming.
Clixlogix rebuilt the platform footprint on AWS with 3 primary pieces.
The cutover ran behind a routing shim that mirrored traffic to both environments during validation, and the credit ledger reconciled against both sides before the final DNS swap. Users saw no interruption during the switch. The subscription and credit state transferred without a single reconciliation discrepancy.
The multi region AWS deployment restored latency parity for the largest revenue cohorts. Enterprise procurement objections about data residency and compliance posture became answerable, because AWS carries the certifications that regional providers cannot present in a US or EU procurement conversation. Deals stuck on infrastructure due diligence started moving through the pipeline.

Fig 2 – Mirrored traffic and a ledger reconciliation checkpoint ahead of the DNS swap, which is why no user saw an interruption.
The move from a single model deployment to a routed portfolio was the highest impact architectural decision of the migration. Model spend is a line item on the P&L, and routing that line item against the actual difficulty of each request pulls margin without touching revenue. It also lifts perceived quality, because the hardest requests finally get the model capable of handling them.
Clixlogix designed a routing engine that maps each request type to the OpenAI model best suited for it. The mapping is explicit and auditable.
| Request Type | Model |
|---|---|
| Default app edits and simple layout JSON | gpt-4.1-mini |
| High quality prompt to layout generation | gpt-4.1 |
| Uploaded sketch, image, and PDF understanding | gpt-4o |
| Hard constraint and layout reasoning fallback | o4-mini or o3 |
| Interior render and visual concept images | gpt-image-1 |
| Template search and style matching | text-embedding-3-small |

Fig 3 – Requests classify into 6 model routes and return through a validation path.
The routing engine reads a per request cost budget and a quality tier, so the client can dial the mix on a per plan or per feature basis without redeploying. Provider outages shift affected traffic to a compatible fallback within seconds, so end users continue working through a model provider incident.
The routing engine instruments every model call and records the full cost and quality profile. Latency is the headline metric. Token cost feeds unit economics. Structured output validity and downstream success both flow into the same profile. The client’s product team sees the real price and quality of each model on actual production traffic. Benchmark comparisons are informative. Production measurements are decisive.
The AI Eval Loop closes on itself. Every routing decision produces a measurement, and every measurement updates the routing tables within configured guardrails. Model provider progress translates into product quality without requiring a release cycle from the client’s engineering team.

Fig 4 – Every routing decision produces a measurement, and every measurement updates the routing tables within guardrails.
Technology Insight
OpenAI offers 2 mechanisms for returning JSON. JSON mode guarantees valid JSON. Structured Outputs guarantees valid JSON that conforms to a specified schema. For a product where the entire downstream pipeline reads a canonical schema, the difference between the 2 is the difference between a validation error at the deterministic renderer and a validation error at the JSON parser. Structured Outputs pushes the failure closer to the source. Handling the failure at the source has lower cost, because the source knows what request generated the failure and can retry with a targeted correction. On this engagement, the move from JSON mode to Structured Outputs collapsed a whole category of downstream error handling and moved the model contract into a first class artefact.
The Core Floor Plan Engine is where every other capability reads and writes. Clixlogix built it as a set of pure functions over a canonical JSON schema, independent of any AI model. That separation keeps the product deterministic and defensible against the churn of model providers.
Structured floor plan JSON schema. Clixlogix designed a canonical document that every plan resolves to, and that every downstream capability reads regardless of how a plan entered the product. Clixlogix versioned the schema so that a plan created in an earlier release stays readable and editable as the schema evolves. Forward migrations run at read time so the database never needs a bulk rewrite.
Constraint and layout solver. Room placement runs through a solver that respects hard constraints and soft preferences. The solver runs after the model has proposed a candidate layout. If the candidate violates a hard constraint, the solver either repairs it or bounces the request back to the model with a targeted correction prompt. That closed loop keeps AI generated layouts genuinely usable in production.
Wall, door, and window geometry engine. Walls have a real thickness. Doors and windows sit inside a wall, and their opening geometry adjusts as the wall moves or resizes. The geometry engine handles every kind of wall intersection deterministically, so a rendered plan never shows visible seams or misaligned wall ends. Snapping and alignment guides read from the same engine the renderer uses, so what the user sees while editing is what the export produces.
Furniture placement rules. Furniture placement respects clearance zones, orientation defaults for a use type, and adjacency to walls.
Placement failures never pass through undetected. These rules run on top of the same schema the model targets, so a prompt such as “add a queen bed to the primary bedroom” produces a valid placement that the user can then nudge without fighting the tool.
Unit conversion. The engine works internally in a single canonical unit. Display and export honour whichever unit system the user prefers, imperial or metric. Rounding preserves clean increments, so a dimension shown as 12 feet 3 inches on one side does not become 3.7338 meters on the other. A US contractor and a European client reviewing the same plan see numbers that agree with their tools.
Export pipeline. Exports produce 5 formats from the same schema without a model in the path.
Exports are repeatable and auditable, and no model ever draws a wall in pixels.

Fig 5 – The canonical schema sits at the centre of every capability, from prompt generation to 5 export formats.
Setback and Resolution
CAD export to DXF looked correct in the internal viewer and correct in AutoCAD. A subset of enterprise users reported broken imports in Revit and BricsCAD. Investigation surfaced that DXF as a specification covers a family of files that different CAD tools interpret slightly differently, particularly for wall thickness rendering and block definitions. Clixlogix added a DXF flavour selector to the export dialog and a per flavour rendering path behind it. Every export now runs validation against target import workflows before release. CAD interoperability remains a moving target, and the team treats it as an ongoing engineering discipline. Enterprise adoption stopped stalling at the import step.
The vision workflow built on gpt-4o handles every kind of upload the product accepts, from a rough sketch to a scanned PDF. The model returns geometry candidates in the canonical schema, and a validation pass cleans them up before the plan reaches the editor.
Uploading removes the highest friction moment in the product, the empty canvas. A user who arrives with a photo of an existing plan can start editing within seconds, and the retention curve for that user looks very different from the retention curve for a user who has to draw from scratch. Every reliable upload is a retained user.
Setback and Resolution
The vision ingestion pipeline performed well on clean phone uploads and clean PDFs. Real users uploaded a wide range of source material, from old low resolution scans to phone photos taken at oblique angles. On these inputs, the vision model returned confidently wrong geometry, which surfaced as broken plans in the editor and generated support tickets that named the AI as the source of the problem. Clixlogix added a pre processing pass ahead of the vision model. Deskewing the image is the most common operation, and denoising and contrast normalization run in the same pass. A confidence threshold on the vision output catches cases where the pre processing was not enough. Below the threshold, the pipeline returns the user to a review step where the user confirms or corrects the extracted geometry before it commits to the canonical schema. Users see the AI ask for confirmation on hard inputs. That behaviour changes the perception of the AI from confidently wrong to appropriately cautious, which is the perception a paid user wants.
The 2D editor runs on a Canvas and SVG surface in the browser with the Nuxt and Vue frontend. Vue Query manages server state, and Redis backed session state lets a user resume an in progress edit on a different device without a save step. The 3D viewer runs on Three.js reading the same schema. Both views stay in sync because they read a single source of truth, and a change made in one surface appears immediately in the other.
Server side thumbnail rendering runs in a dedicated worker pool. Higher resolution walkthrough renders route to an offline job queue and land in object storage as MP4 files. Rendering never runs on the request thread of the web API, so a slow render never affects the responsiveness of the editor.
The NestJS API is the single entry point for every client. The web frontend, the mobile companion, and third party integrations all reach the platform through the same API. Its security model has 3 elements.
Uniform response envelope. Every route returns responses through a single envelope shape. Successful responses and error responses share the same structure, so the frontend and every downstream integrator handle all responses through one code path. Error handling lives in one place and covers every endpoint automatically.
HMAC signed API requests. Protected requests carry HMAC signatures based on the client’s API secret. Timestamp and nonce validation prevent replay. The configuration defeats replay attacks and defeats casual credential theft even if a JWT leaks.
Global middleware. Cross cutting concerns run as global NestJS middleware. No controller has to duplicate authentication, rate limiting, or request validation, and no controller can accidentally skip them. Rate limits are configurable per client and per plan tier. Logs carry the request id through every downstream service call, so a single log entry traces a request end to end.
Google Sign In handles primary authentication with a JWT session issued on successful login. Optional email and password login serves users who prefer it. HMAC signing runs alongside JWT authentication for machine to machine calls and for the mobile companion, which cannot rely on a browser session.
Technology Insight
The API uses 2 authentication mechanisms together. JWT identifies the user and carries session state. HMAC signing proves the request came from an authorized client on every call. HMAC uses a shared secret with a timestamp and a nonce, and that recipe defeats replay attacks and defeats casual credential theft even when a JWT is exposed. Machine to machine calls and mobile clients both need HMAC on top of the JWT, because neither has the secure cookie storage a browser provides. A leaked JWT alone gives an attacker nothing usable if the API enforces HMAC. That configuration is what lets the security page answer an enterprise procurement question with a straight face.
Long running work runs through a BullMQ job queue on Redis. Dedicated worker fleets handle each job type, from AI generation through export. Every job carries a hard cost cap, so a runaway prompt cannot overrun a user’s credit balance or exhaust a worker fleet through a misbehaving upload. Priority lanes make sure a paid user’s export does not queue behind a free user’s background regeneration.
The queue exposes depth, throughput, and failure rate instrumentation. When any of those metrics drifts, the observability system surfaces the drift before it becomes user visible.
Clixlogix built a credit ledger that debits every billable action, from a generation through a render to an export. Cost drivers account separately so the client sees the true unit economics of any feature at any tier. Stripe handles the full billing surface, and every Stripe webhook lands in the ledger through an idempotent handler, which means a webhook retry never double credits or double debits an account.
Every ledger movement flows through the same audit log, which is the single source of truth for a user’s credit balance. Billing accuracy is a trust variable. A single miscounted credit escalates from support ticket through refund to review site complaint faster than the credit ever generated.
Model spend by route flows into an observability dashboard daily, so the product team adjusts routing rules against real production measurements.

Fig 6 – The idempotent webhook path is what keeps the ledger consistent under retries and failures.
OpenTelemetry traces and application logs flow into a single observability dashboard covering every metric the operations team needs to spot a problem before users do. Filters isolate a specific account in a single hop.
Abuse controls combine hard rules and heuristic scoring, with the specific rule set kept internal. The admin console lets the operations team act on any abuse case within seconds. Abuse that surfaces before a chargeback is abuse that costs the client nothing.
The mobile companion is currently under active development. It lets a user capture a real room by walking through it with a phone and produce an editable floor plan without a drawing step. The addressable market for a product that requires a user to walk through a room is much larger than for a product that requires them to draw one.
The capture pipeline runs on device with computer vision inference for room geometry. On iOS devices that carry LiDAR, depth data augments the visual signal for higher accuracy. Devices without LiDAR fall back to visual scale estimation using a reference marker or a user calibration step.
Captured geometry normalizes into the canonical schema on upload, so the same plan opens in the web shell and exports through the same pipeline. Users who prefer to stay on mobile can review and edit the capture in the app itself, and users who prefer the full editor pick up the same project on desktop.

Fig 7 – Camera and optional LiDAR feed on device inference, normalizing into the canonical schema. Preview, the app is still in development.
Design and delivery details for the mobile companion remain in active definition. A follow up case study will document those details when the app reaches production.
Consulting Insight
A single canonical schema is the most important architectural decision in an AI product. Every capability that reads or writes it becomes composable with every other capability. Change the schema well and every capability upgrades. Change the model well and no capability breaks. On this engagement, the schema made the migration from Qwen to a routed OpenAI portfolio survivable, and it turns the mobile capture pipeline into a schema addition. No downstream capability needs a rebuild.








Beyond the numeric outcomes, the engagement moved the platform into a commercial posture it could not previously hold.
The migration paid back in commercial terms alongside the technical ones.
| Category | Technologies |
|---|---|
| Cloud | AWS compute, Amazon S3, CloudFront, Cloudflare CDN, WAF, and DNS |
| Frontend | Nuxt 3, Vue 3, Tailwind CSS, Vue Query, Canvas and SVG editor, Three.js |
| AI Models | OpenAI gpt-4.1-mini, gpt-4.1, gpt-4o, o3, o4-mini, gpt-image-1, text-embedding-3-small |
| AI Capabilities | OpenAI Structured Outputs, Vision, embeddings for template retrieval |
| Backend API | NestJS with HMAC signed requests, uniform response envelope, and global middleware for auth, rate limiting, request validation, and structured logging |
| Auth | Google Sign In, JWT sessions, HMAC request signing for protected routes and machine to machine calls |
| Data | PostgreSQL, Redis |
| Job Queue | BullMQ on Redis, dedicated worker fleets for generation, sketch parsing, rendering, and export |
| Floor Plan Engine | Structured JSON schema, constraint and layout solver, wall and opening geometry engine, furniture placement rules, unit conversion across feet, inches, meters, and centimetres |
| Rendering | Three.js viewer, server side thumbnail workers, offline high resolution renderer for walkthrough MP4 output |
| CAD Export | PNG, JPG, PDF, SVG, DXF from the canonical schema, with a flavour selector for CAD tool specific DXF |
| Payments | Stripe with an internal credit ledger and an idempotent webhook handler |
| Observability | OpenTelemetry, structured application logs, cost and abuse dashboards |
| Mobile Companion (in progress) | Computer vision capture pipeline, on device inference, LiDAR augmentation on supported iOS devices, synchronization into the canonical schema |
Our team can share client references, scope your project, and answer any question about your delivery.
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.