case study · Commercial tool · Full-stack

Aluminum Joinery Quoter

An aluminum joinery quoter that gives credible prices, not made-up numbers.

RoleSole full-stack developer — product, pricing engine, backend, database and securityClientGrupo CPS — aluminum-and-glass joinery industryYear2026

Let's talk about the projectThe code is private since it is a client project.

Next.js 16ReactTypeScriptTailwindCSS 4SupabasePostgreSQLRLSJest

2.44× → ~1%

How much the error in calculating the aluminum dropped, compared to the factory system. I did not fix it with a hand-tuned fudge factor, but by understanding where the difference came from.

A web app where the client builds their order of aluminum-and-glass windows and gets an estimated price. The challenge was not the screen, but getting the price right: what looked like a simple formula actually depended on how much aluminum and glass each window really uses. To get it right, I studied the 2,641 real recipes from the factory software and pulled out the numbers that drive the cost.

The problem

Grupo CPS manufactures aluminum-and-glass joinery. Quoting each order by hand is slow and depends on technical staff. They wanted a simple web app where the client signs up, builds a cart with their windows, sends the order and tracks it.

The problem was in the word "simple". The price of a window does not come from multiplying area by a price per square meter: it depends on how much aluminum profile each window type uses (the frame, the opening sash, the bead that holds the glass, the transoms) and on the real glass measurement, plus hardware, labor, margin and VAT.

The company already calculated all of this precisely in its factory software, WinMaker, which stores one "recipe" per window type: 2,641 files in a closed format, impossible to use directly on a website. My first simple calculation fell far short: it counted 2.44× less aluminum than the window actually uses.

the key decision

Pull from the recipes only the numbers that move the price, without copying the whole factory software.

I had two bad options: a simple formula (fast but false) or rebuilding the entire factory software (precise but unfeasible). I chose the middle ground: read from the recipes only the measurements that affect the cost.

The error was not a wrong number, it was structural. The simple formula counted only the outline of the frame. But a real window holds much more aluminum: the frame, the opening sash, the bead that holds the glass and the transoms. And the glass is measured by the real opening that is left, not by the total size of the window.

So I built a program that reads those 2,641 recipes and pulls out, for each window type, the exact measurements the factory already uses. Those measurements feed the pricing calculation that already existed: what changes is how much material is counted, not how the price is built.

Simple formula calculated4.32 m

Aluminum it really uses~7.7 m

Concrete example: for a 1×1 m fixed window, the simple formula calculated 4.32 m of aluminum profile. In reality it uses about 7.7 m (the frame plus the bead that holds the glass). That gap, together with how the glass is measured, explains the 2.44× with nothing made up.

the solution

A full-stack app with a pricing engine at its core.

01
Sign up and log in
Each client has their own account.
02
Building the window in 3D
The client picks type, dimensions, line, glass, color and accessories, and sees the window rendered in 3D, which they can rotate to look at from any angle.
03
Cart with several windows
They group several windows into one order and build their quote like a draft: adding, removing and adjusting until it is the way they want.
04
Quote as a PDF
With one click it generates a clean PDF with all the windows, their specs and the total, ready to save or share.
05
Order that gets frozen
On submit, the prices and names of that moment are saved. Nothing is recalculated behind the scenes afterward.
06
Tracking
In "My orders" they see the status of each one, and can share a summary via a private link.

The quoter does not come to replace WinMaker, the system the factory has always quoted with: it is the client’s front door. An intuitive, eye-catching first approach where they can build their window, try combinations and clear up their doubts on their own. And for Grupo CPS, a way to capture every quote requested and give it orderly follow-up. Behind it, the client never sees internal costs or margin: all the calculation happens on the server and only the final price reaches the browser.

architecture

A strict boundary between public and private.

Browser

Configurator · cart · my-orders.

API

app/api/*

HTTP boundary: auth, authorization and DTOs with no sensitive data.

SRV

src/server/*

Private logic: queries, persistence, service-role.

CALC

src/lib/cotizador/*

Pure pricing engine, no I/O, 100% testable.

DOM

src/technical/*

Types, normalization, compatibilities and validations.

supabase/schema.sql

Canonical PostgreSQL with Row-Level Security.

The part that calculates measurements is separated from the part that builds the price. That is why bringing in the factory numbers changed the material quantities without touching the pricing logic, and the whole calculation can be tested on its own, with no database.

security by design

There is client data and internal costs at stake: security was a requirement, not an add-on.

No data served straight from the database

Everything goes through the server with login. The database master key lives only there, it never reaches the client’s browser.

Share links impossible to guess

A summary link is not a running number (1, 2, 3…) but a random code, so nobody can change it to peek at other people’s orders.

Inputs always bounded

Dimensions up to 6000 mm, integer quantities with a cap, limited text. Nothing gets in without checks.

Internal costs never exposed

The client sees the final price, never the cost, the margin or the price per square meter. All the calculation happens on the server.

quality & engineering

Measure before you claim.

Factory recipes analyzed: 2,641
Automated tests (Jest): 68+
Material error vs. the factory system: 2.44× → ~1%
Code quality: Strict TypeScript, no type errors

The "shadow mode": a tool that compares, window by window, what my system calculates against the real parts breakdown from the factory software. It measures how far off I am before calling a price good. The difference between "I think it’s right" and "I measured it".

demo

The quoter in action.

System walkthrough: from building the window in 3D to the submitted order.

3D visualization: the quoted window rotates to be seen from any angle.

Generated PDF with the assembled quote — PDF generated automatically with the assembled quote, ready to save or share.

why this project represents me

The hard problem is rarely the visible one: the screen was the easy part, the value was in calculating well and validating the numbers.
I did not brute-force copy the 2,641 recipes: I pulled out only what moves the cost and left the rest as separate research.
Measure before you claim: "shadow mode" turned a hunch ("the price doesn’t add up") into a number (2.44×) and then into a validation (~1%).
Security and traceability from day one, not as a patch.

Got a calculation or an operation that a simple formula can’t pin down?

That’s the kind of problem I enjoy. The code for this project is private, but we can talk about it.

Let's talk about the project