WAGGER — A VEHICLE FAMILY, AND THE SYSTEM THAT BUILDS IT

The Problem

A custom-vehicle company's greatest strength — building exactly what a customer needs — is also where it bleeds: every custom order is treated as a fresh engineering project (geometry redrawn, part lists derived by hand, knowledge living in people's heads); single-unit orders can't amortize fixture and setup costs, so the most profitable niche is avoided; and because every vehicle is unique, after-sales service means sending an engineer with a laptop. The common root cause: no unbreakable chain between a vehicle's identity and its production and service information.

The Thesis — Three Independent Bets

The bets are deliberately decoupled: if fixture-less assembly needs revision, the module and configuration systems still stand — and vice versa.

System Architecture — Config to Workshop

The pipeline turns a configuration file into a complete, audited production package with no manual CAD work in between:

• Configuration layer. A vehicle is described as data: size class, wheel and drive layout, speed band, operator profile, attachments. Presets keep the configurator from ever starting on a blank page.
• Rule engine. Engineering judgment encoded as executable gates, applied automatically at configuration time: load-class limits, tipping and center-of-gravity checks, operator ergonomics and occupational-safety rules. An invalid combination is rejected before any CAD exists.
• Identity chain. Config → configuration ID → serial number → laser marking. Every physical part can be traced back to the exact data that produced it — the after-sales answer is designed in, not bolted on.
• Parametric CAD layer. A pure-geometry core computes the layout (centerlines, pockets, axes, mass and center of gravity) independently of any CAD package; scripted Fusion 360 stages then build the skeleton, panels and tubes from it. The same geometry is never implemented twice.
• Audit gates. Before a package is released, blocking audits check completeness, part typing, bend and contour validity, and that every rule block actually executed. A package that fails does not reach the workshop — the gates stop it loudly instead of warning quietly.

What One Run Produces

A single unattended run derives, for one serial-numbered vehicle, a complete production package:

• DXF flat patterns for laser cutting, with self-locating tab-and-slot geometry and marking layers
• Bend drawings and tube bending data
• Weld plans with numbered assembly order for the workshop
• Mass, center-of-gravity and engineering reports
• Part visuals and step-by-step assembly frames
• A versioned archive entry tying it all to the serial number

From Customization to Mass Customization

Automating the design alone would only have made engineers faster. The step that changes the business is automating the production files themselves: when cut files, bend data, weld plans and numbered assembly cards are generated — not drawn — for every serial number, "custom" stops being the opposite of "series". Each vehicle can be unique, yet the workshop consumes identical-looking, machine-ready packages every time.

That is mass customization by construction: batch-of-one economics with series-production discipline. The pipeline that derives one vehicle can derive fifty different ones in an afternoon — batch orders run through the same identity chain (config → serial → package), operators read the same document format regardless of how unusual a configuration is, and the audit gates apply uniformly to every unit. Variety moves out of the workshop, where it is expensive, and into the data, where it is free.

And because every package is machine-readable by construction, the same files that instruct a human welder today can feed automated cells tomorrow — which is exactly where the roadmap below takes it. Customization automation, production-file automation, mass customization, mass production: one system, evolving in that order.

One Data Spine — The Tıkır Integration

Wagger does not live alone: it connects to Tıkır, the AI-native business platform, and the two share one data spine. An order captured in conversation in Tıkır becomes a Wagger configuration; the configuration becomes a serial number, a specification and production notes; and every datum flows back into the same record for after-sales. Sales, engineering, production and service operate on one identity chain — and because both systems are single-source and config-driven by construction, the data crossing between them is structured and regular. Nothing is re-typed, nothing is reconciled, nothing drifts.

The most visible payoff lands in the sales meeting itself. Because a vehicle is a configuration and the pipeline can render one, the customer's vehicle can be configured during the meeting — and a mockup of it shown on the spot, while the requirements are still being discussed. The visual the customer reacts to, the quote they receive and the production package the workshop will eventually build from are all derived from the same config. The meeting doesn't end with notes to be turned into a design later; it ends with the vehicle already defined.

Speed — Two Weeks of Engineering in Under an Hour

This is where the system changes what a custom order means. The engineering behind one custom vehicle — redrawing geometry, deriving part lists, preparing cut, bend and weld documents, checking it all — used to consume roughly two weeks of an engineer's time. The pipeline does the same work unattended in well under an hour: the chassis stage alone regenerates in fifteen to twenty minutes, and a complete, audited, production-ready package exists before a traditional process would have scheduled its first design review. That is not an incremental speed-up; it is roughly two orders of magnitude, and it is what makes a production run of one economically ordinary rather than exceptional.

Regeneration is total by design: the package can always be re-derived from scratch, so there is no stale file to trust — and a design change costs another hour, not another two weeks.

And the hour is not a rushed hour — the quality goes up, not down. Speed usually costs quality: on a tight custom job the bill of materials is the first casualty, incomplete or improvised, and every gap in it resurfaces later as a production delay. Here the work runs inside a fixed standard, so the same hour that produces the cut and bend files also delivers, for that specific vehicle: a true, complete BOM; a vehicle-specific user manual; the engineering documentation (mass, center of gravity, load and stability calculations); and a welding guide with numbered assembly order for the workshop. The audit gates refuse to release a package with anything missing — so the fastest process is also the most complete one, on the first vehicle and on the fiftieth alike.

Reliability comes from the same place: no value lives in two places (documents reference parameter IDs; only the registry holds numbers), every design decision is recorded with its rationale and the alternatives that were rejected, and the audit gates block rather than warn. The gates have caught real errors — including, on one occasion, a defect introduced the very day the gate itself was written.

One Button, Another Continent — Market Localization

A consequence of generating everything from one data spine: the market a vehicle is built for is just another input. At a single command, the same order re-emits as a US-manufacturable production package. That is not a unit relabel — the system re-resolves the design against imperial stock: material thicknesses and section sizes are swapped to their imperial equivalents, every dimension in the drawings and documents is converted accordingly, and the language of the entire package — manuals, weld guides, engineering documentation — switches to match the target market.

In a traditional workflow, entering a new market with different material standards is a re-engineering project measured in months: every drawing revisited, every thickness re-justified, every document retranslated and then maintained in parallel forever. Here it is a build target. One design, one record — and a package a workshop in İstanbul or in the United States can each manufacture from directly, with no second engineering effort and no second set of files drifting out of date.

The Endgame — Order in the Morning, Deliver in the Evening

Once engineering takes an hour instead of weeks, the bottleneck moves: the remaining lead time on a custom vehicle is physical — cutting, bending, welding, assembly — and that flow can now be organized around a package the system emits automatically, with every part arriving identity-marked and self-locating. Optimizing that production flow is part of the program, not an afterthought.

The long-term roadmap takes the idea to its conclusion: robotic laser cutting, bending, welding and assembly cells consuming the production package directly. The chassis was designed for this from day one — fixture-less tab-and-slot joints are exactly the geometry robotic assembly handles well. The target is simple to state: a customer orders a custom vehicle in the morning and takes delivery the same evening. With the information chain already automated end to end, what remains is a scheduling and automation problem — a roadmap, not a dream.

How It Was Built

I did the mechanical and system engineering; the software was built by directing AI coding agents (Claude) against that engineering record. The docs-as-code discipline is what makes the combination reliable — the agents work from the same single source of truth as the pipeline, and the gates audit their output like anyone else's.

← Back to portfolio  ·  CV