Product engineer.
The product, the system behind it, and the interface on top.
3 products, each a different kind of engineering: an AI platform built around a strict schema, a 3D try-on wired into an e-commerce platform, and operational software across desktop, mobile and an API. Point at a name to see the interface; open it for what I built, what the product needed and what the demo does and doesn’t cover.
I work across the whole product: what it should do, how it is structured, the data and API behind it, the integrations it depends on, the interface in front, and getting it running. I can start from a requirement you already have, or help shape the product before anything is built. I care most about the part users never see, the system the interface sits on, and I make the pragmatic technical call and say why.
Product thinking and architecture
Before code: what the product has to do, who it is for, what the architecture has to carry and what can wait. I would rather settle that in a few conversations than discover it in the codebase. I can start from a requirement you already have, or help shape one.
Backend, APIs and data
The part behind the interface: the data model, the API, authentication, tenancy. Senzovia is the clearest case: stock modelled as a ledger of movements, one Cloudflare Worker API, and a shared core under a desktop client and a mobile client.
Interfaces that match the system
The interface is built against the real system, not a mockup of it, and it is designed for the person using it: a 3D fitting cabin on a shop’s product page, a visual builder for generated sites, a stock screen for a factory.
Integrations and shipping
Products live inside other systems. Karyamoni connects to the IKAS store platform with an OAuth flow, signature-verified webhooks and product sync; Yappaflow carries connectors toward four CMS platforms. I deploy what I build.
AI where it actually helps
A model is one component with a cost and a failure mode, so the decision is where it belongs. Yappaflow constrains generation to a schema so the output can be edited and validated. Senzovia keeps stock rules deterministic and treats computer vision as one more input.
A factory
counts by hand.
So I started
with the work.
Before any code I wrote down how the work actually happens: who counts, who ships, what ends up in Excel, and what has to stay true. The product is that workflow, made reliable.
- Products and SKUs
- Stock and movements
- Counting sessions
- Customers and shipments
- Excel import and export
- Desktop and mobile clients
One ledger owns
the truth.
Stock never
goes negative.
The rule lives in the system, not in the screens. The screens can stay simple because the thing underneath them is strict.
One path for every input.
It is a prototype, and the screenshots on this site use invented sample data, so I make no claim about outcomes. What it does show is the work: a model with rules, two clients, and Excel import and export so the old way can be carried across.
Product
first.
I start from what the product has to do and who it is for, then make the engineering decisions that serve it: the model, the boundaries, what can wait. The code follows from those.
Senzovia is one product. Karyamoni and Yappaflow are others, with different problems and different engineering. If you have a product to build, or one that needs an owner, this is how I would work on yours.
- 01
Understand
I start with the problem, not the feature list: who it is for, what they do today, what that costs them, and what would count as working. If I can’t say it plainly, there is nothing to build yet.
- 02
Decide
I settle the smallest version that tests the idea, and the decisions it has to survive: the data model, the boundaries between parts, what must be real now, what can be faked, and what can wait.
- 03
Build
I build the layers together — data, API, integrations, interface — so they agree with each other. I use AI coding tools for speed; the architecture, the decisions and the review stay mine.
- 04
Shape the interface
I put real screens in front of you early, because a working interface settles arguments a document can’t. The people using the product feel the interface, so it gets the same care as the system underneath it.
- 05
Ship and iterate
I ship something real, then change it based on what the product turns out to need. I check it against what we said would count as working, and where I can’t show that, I say so.
I make the call, say why, and change it when the product shows me I was wrong. Pragmatic beats clever: the right decision is the one the product can live with.
What the work is made of, taken from the three products and checked against their repositories and demos. These are facts about what I built, not usage figures: none of it is a user count, a revenue number or a production claim, and each line says where it comes from.
≈ 500
Product varieties a Romanian PVC factory counts by hand and types into Excel. The data model and the Excel import are built around that workflow.
2 clients, 1 API
A desktop app and a mobile app over one Cloudflare Workers API, with the domain rules and validation in a shared core package both clients and the API import.
24 h
A retried request replays its stored response instead of booking a second stock movement, and a stock change and its ledger row are written in one atomic batch.
OAuth + HMAC
The IKAS app uses an authorization-code flow with token refresh, and verifies incoming webhooks by signature before acting on them.
TR / EN
A 3D garment viewer on a mock product page, a guided walkthrough and a playground, in Turkish and English.
1 schema
The AI fills one canonical JSON project instead of writing free-form pages, so the visual builder and the CMS exports work from the same structure.
Senzovia: why the ledger is the source of truth
Stock as movements, tenancy enforced in the database, and what a computer-vision result has to pass before it can touch stock. In the repository’s architecture and decision documents.
Karyamoni: what the first version leaves out
An IKAS-first scope, tops before the rest of the wardrobe, and the assumptions that still have to be confirmed. In the product plan, MVP spec and technical architecture.
Where my attention goes between projects, and the questions I would bring to yours. It changes; that’s the point of writing it down.
Counting without a person in the loop
Senzovia’s stock ledger works. The harder product is the one where a camera does the counting and a person is called only when the system is unsure. So far that exists only as an isolated experiment, and the open question is what the ledger has to refuse before a vision result is allowed to touch stock.
How much structure an AI feature needs
Yappaflow works because the AI fills a strict schema instead of writing free-form pages. I want to find where that stops being enough: which parts of a product want a schema, which want judgement, and who decides.
A fit recommendation you can believe
Karyamoni’s demo uses illustrative fit values. A real size recommendation needs real garment measurements and an honest account of how sure it is, and I don’t yet know how much of that a merchant will realistically provide.
One product, several surfaces
A desktop client, a mobile client and an API sharing one core is a good deal until a screen needs to behave differently on each. I keep coming back to where the shared layer should stop.
Knowing what a product is doing
I’m working out how little instrumentation is enough to make a product honest about itself — what is used, what is slow, what fails — without turning every feature into a monitoring project.
I’m a product engineer. I work on what a product should do, how it should be structured, and then I build it: the backend and data, the APIs and integrations, the interface, and getting it running. I use AI where it earns its place in the product, not because it is expected.
I work alone, so one person owns the whole thing: the decision, the code and the consequences. That suits a founder getting a product off the ground, a team that needs an internal tool built properly, or a company with software that needs someone to take responsibility for it. I can start from a requirement you already have, or help shape the product first.
I use AI-assisted development as a tool, the way I use a type checker or a debugger. It speeds the work up; the architecture, the decisions and the review stay mine. And I keep the product honest by checking it against reality: what it does, what it costs, and where my first idea was wrong.
A new product, an internal tool, or the system behind an interface that already exists. If the problem isn’t pinned down yet, I can help shape the product and the architecture before anything is written. Tell me what it is, who it is for and when you need it. I answer with what I would build, in what order, and what I would decide first — and I say so when what I learn along the way contradicts the plan, including mine.