Ginani Pattern Engine

Ginani Patts digital pattern engine creates custom-fit and standard-size PDF sewing patterns, then uses YouCam Apparel VTO to help users visualize designs on themselves before even sewing them.

Comment

Inspiration

I run a small fashion business, and because of AI the tools available to a one-person operation have changed completely. What I built here would once have needed a team of engineers and a budget I do not have.

The problem itself is much older. Anyone who sews knows the gamble. You buy a flat paper pattern. You take your measurements, cut into your fabric, and sew for hours or days — and only at the very end, when the garment is finished and the fabric is spent, do you find out whether it actually suits you. The moment of truth arrives after all the work is done, when it is far too late to change your mind. That risk is why most people never buy a second pattern.

What it does

Ginani Patts is a platform for buying sewing patterns where you get to see two things before you commit.

You see the pattern the actual pattern pieces, drafted to your own measurements, generated on the spot. You know what you are buying and what you will be sewing before any money changes hands.

You see yourself wearing it. Save a full-body photo, tap try on, and virtual try-on renders the garment onto your image. The proportion, fit and style on you, not just imagined from an image.

Then you buy. The pattern is drafted to your measurements and tiled across whatever paper is in your printer, at exact 1:1 scale, with printing instructions and a construction guide. Some designs offer choices — three necklines shown as pictures rather than described in words — and the engine drafts whichever one you pick.

The sequence is: see it on yourself, see the pattern, choose your variation, print at home, sew. A picture of yourself wearing the garment creates a connection no line drawing ever will.

How we built it

A drafting engine. I author each design in PatternMaker 7.5 using its MacroGenerator, which produces a parametric macro: a script whose instructions compute points and curves from measurement variables. The engine is essentially a compiler — it parses the macro language, translates it into executable form, runs it against a customer's measurements inside a constrained runtime, arranges the pieces so nothing overlaps and every label stays attached to the piece it belongs to, and renders the output. The same pipeline produces both the on-screen preview and the printable file.

A print pipeline built for true scale. Patterns are rendered at exact 1:1: one inch is exactly 72 PDF points, so the geometry is right by construction rather than by conversion, and regression tests verify the physical dimensions of every generated file. Output tiles automatically across whatever paper the customer has — A5 through A0, US Letter, Legal or Tabloid.

Files then defend that scale on the way to the printer. Each one sets the PDF flag instructing readers not to resize, opens with a printing guide, and carries a one-inch calibration square and ruler on every page. The customer measures it once before cutting and knows immediately that the sheet in front of them is true to size — a five-second check that stands between a print-dialog setting and a ruined length of fabric.

A try-on layer. This runs entirely server-side against YouCam's apparel API: the server requests upload slots, sends the customer photo and the garment image, creates the task and polls for the result. The API key never reaches browser JavaScript. Usage is reserved atomically against both a per-account allowance and a global budget, so a burst of traffic cannot silently exhaust the allocation. Privacy The try-on service never receives your measurements or any pattern data — it works from a photo of the finished garment alone. Try-on answers does this style suit me. Your measurements drive the drafted pattern, and they answer will this fit. We present the preview as exactly that, never as a fit guarantee.

Administration Around those sit accounts, private dashboards, reusable measurement profiles, saved try-on photos, purchased-pattern libraries and an administrator console.

Stack: FastAPI on Python 3.13, ReportLab for PDF generation, Pillow for image verification, Neon PostgreSQL over psycopg3, deployed on Render with GitHub Actions CI. 61 tests, passing.

The frontend is deliberately plain: hand-written HTML, CSS and vanilla JavaScript, no framework and no build step. The interface is a catalogue, a customer dashboard, an admin console and a help page — at that size, a frontend framework would have added a toolchain to maintain without making anything easier. Keeping it dependency-free means the pages load fast and there is nothing between the source and what runs in the browser.

On AI-assisted development: I built this working with Codex, Claude and Antigravity across different parts of the stack, and the commit history shows it plainly. What I want to be equally plain about is where that stops. The models write good code quickly. They do not know what a correctly drafted facing looks like, why a grainline matters, or that a curve computed from the wrong control points produces a neckline that will not close. Every hard bug below was caught because I know patternmaking. The bottleneck moved from can I build this to do I know what correct looks like — and domain expertise turned out to be the scarce input.

Challenges we ran into

Curves, three times over. Getting arcs to render correctly was the hardest problem in the project. My first attempt drew them as construction guides rather than finished curves. The second fixed the shape but misplaced the endpoints. Only the third — rebuilding each curve from its tangent controls — matched the source. A curve a few millimetres wrong is a neckline that will not meet its facing, and the customer finds out after cutting into their fabric.

Laying out pieces is not just packing. Drafted pieces frequently overlap when they come out of the engine. Separating them is easy; separating them correctly is not, because notches, grainlines and text labels have to travel with the piece they describe rather than being shoved aside as independent objects. The layout stage checks whether an annotation sits inside a piece's boundary to decide what moves and what stays attached.

Running out of memory in production. Complex designs with deep option trees exhausted memory on the production instance and took the whole service down. The fix capped how far those trees expand and serialized generation, so concurrent requests queue rather than compete for the same limited memory.

A security hole in fetching results. Wiring up try-on was tractable once I understood the inputs it expects. The uncomfortable part was retrieving results: the service returns a URL, and naively fetching a URL supplied by an external service is a server-side request forgery vulnerability. The client now requires HTTPS, resolves the host, rejects any address that is not publicly routable, and re-validates on every redirect.

Sandboxing before I needed to. Because patterns are programs, generating one means executing code. Every design in the app today is one I authored myself, and raw pattern upload is administrator-only — so right now the only person whose code runs on that server is me. I sandboxed it anyway, because the multi-tenant version does not work otherwise: the moment an outside designer uploads their own work, I am running code I did not write, and retrofitting a security boundary under a live service is not something I wanted to attempt later. Generation runs in a separate process with hard CPU, memory, output-size and wall-clock limits, and results are validated by file signature rather than trusted.

Making people comfortable uploading a photo of themselves. Not a code problem, and the one I thought about longest. Saved photos are private and retrievable only by their owner, customers can erase their entire try-on history at any time, and account deletion is permanent and self-service.

Accomplishments that we're proud of

Bringing virtual try-on to home sewing. Try-on exists in retail — you can preview a dress before it ships. Nobody had pointed it at people who make their own clothes, where the gap between choosing and seeing it on yourself is not a shipping delay but weeks of your own labour. That is exactly where the technology is worth the most, and exactly where it was not.

Both previews are real. The pattern preview is generated by the same engine that produces the file you print — not an illustration standing in for it. The try-on is a genuine rendering on the customer's own photo.

61 tests and CI on every push, covering rate limiting, sessions, quotas, upload verification, request forgery protection and print-scale regression. For a solo build, I am glad hardening was its own piece of work rather than an afterthought.

What we learned

The constraint was never capability. It was willingness to be wrong repeatedly and keep correcting. The curve renderer took three full attempts, and each failed version looked fine until I checked it against a shape I already knew.

I also learned where AI-assisted building ends. The models are excellent at code and useless at judging whether a garment is correctly drafted. That division turned out to be the whole story of this project.

What's next for Ginani Pattern Engine

Try-on belongs earlier than the moment of purchase. It belongs inside the work.

A patternmaker drafting for a client raises a dart, adjusts a neckline, changes a hem — and has no way to show that client the result until a toile is cut and fitted. Toiles cost fabric, cost hours, and require the client to physically show up. Most fitting decisions get made by describing them out loud and hoping the client is imagining the same garment you are. Then the toile comes back wrong and the loop starts again.

The next version of this is try-on integrated into the CAD drafting pipeline. The drafter alters the pattern; the client sees the altered garment on their own body. Fit conversations stop being verbal and become visual. For a dressmaker working to commission, that is the difference between one toile and three — or between a client who approves confidently and one who is quietly disappointed at the final fitting and never comes back.

It is a different customer from the home sewist this platform serves today: professional patternmakers and dressmakers, working on commission, for whom every avoided fitting round is billable time recovered. But it is the same engine, pointed one step further up the workflow.

Three things stand between here and there.

Rendering from geometry rather than photographs. Try-on today works from an image of a finished garment. Inside a drafting session there is no finished garment — there is a pattern in progress. The visualization has to be generated from the drafted geometry itself, so what appears on the client is genuinely the pattern currently on the table rather than a stand-in that resembles it.

Curve fidelity. That only works if the geometry is faithful. Scale is already exact and tested; reconstructing every curve type correctly is the ground still to cover. I can measure progress precisely, because I have ground truth — drafting the same design in PatternMaker and comparing tells me exactly where the engine diverges.

Latency. A drafting loop is interactive. Try-on that takes thirty seconds is a demo; try-on that keeps pace with someone adjusting a curve is a tool. That is an engineering problem in caching, incremental regeneration, and knowing which edits actually change the silhouette.

The engine is already an HTTP service rather than a monolith, which is what makes any of this plausible — a drafting tool would call the same endpoints the browser does. But the honest summary is that the visualization has to become as accurate as the pattern before it can be trusted inside the process that makes the pattern. That is the work.

A pattern that drafts beautifully and fits wrongly is worse than no pattern at all. A visualization that does not match the pattern behind it is worse than no visualization. Getting both right, in the same loop, at the speed someone actually works — that is what this is for.

Built With

Share this project:

Updates

Submission history