“We shipped an AI-built prototype. Now it has to hold up.”
It works and customers are in it — but the permissions, data model and edge cases were never actually designed.
Two Senior Product Engineers
Building software got easier. Building good software didn’t.
We build new products and turn AI-built prototypes into production systems — owning product, UX, architecture and engineering end to end.
- 10+ years each
- Full-stack ownership
- Startups → enterprise
- Product + engineering
- AI-native workflow
Where teams usually find us
“We need a product built, not a team hired.”
Funding is there, the roadmap is there, hiring four people first is not the plan.
“The hard part is nobody’s job.”
The AI feature, the data model, the migration — the work the team keeps deferring.
01 — Selected work
Private repos, so: the systems, not the screenshots.
01 · Automotive platform
From AI-built prototype to production platform
A Lovable/Supabase app was already holding customer data on a model that couldn’t support it. We rebuilt the schema and permissions, then automated the operations on top.
- listing prep 40 min
- under 5 min
- single dealer
- multi-tenant
- no access control
- row-level policies
React · TypeScript · Supabase · AI
02 · AI workflow platform
Complex enterprise workflows made usable
Operators needed to build and run reusable AI workflows without engineering in the loop. We designed the product model and built the engine underneath it.
- trigger
- steps
- tool calls
- review
- output
Next.js · Node · Postgres · Queues
03 · Document intelligence
A retrieval product a compliance team trusts
Extraction was accurate most of the time, which no audit accepts. We rebuilt retrieval around verifiable citations and hardened it for enterprise tenancy.
- “usually correct”
- cited to source
- silent failures
- review queue
- shared tenancy
- isolated per customer
RAG · Postgres · AWS
Everything above is under NDA or in a private repo. On a call we’ll go through the architecture and the trade-offs in as much depth as you want — and put you in touch with the people we built it for.
02 — Why two engineers
Two senior engineers. No layers in between.
Direct communication
You talk to the people making the decisions.
Senior execution
No junior work handed down the chain.
Small-team velocity
Two people delivering what used to need a team.
Shared ownership
Both of us hold the whole product, not tickets.
03 — What we do
idea → production
Build the product
From vague requirements to architecture, UX, implementation and shipping. You bring the direction; we turn it into working software.
prototype → production
Make the prototype real
Permissions, tenancy, data modelling, testing, observability, infrastructure — the edge cases demos don’t encounter.
hard problem → shipped
Own the hard part
Agents, automation, data pipelines, integrations, migrations — the work your team keeps deferring.
04 — AI-native engineering
AI is leverage, not ownership.
We use coding agents heavily throughout development. Architecture, product decisions, security, review and production reliability stay with us.
- 01Product problemus
- 02Architecture & specificationus
- 03AI-assisted implementationagents
- 04Engineering review & verificationus + CI
- 05Productionowned
05 — Technology
- React / Next.js
- TypeScript
- Node.js
- PostgreSQL / Supabase
- AWS Vercel Docker React Native OpenAI Anthropic Redis Queues
Technology is selected around the product rather than the other way around.
06 — About
Igor
Senior Product Engineer
Full-stack engineer with a product, UX and frontend-architecture bias. Turns a vague business problem into screens and system boundaries that still hold six months later.
product · ux · frontend architecture
Srdjan
Senior Product Engineer
Full-stack engineer with a backend, data and infrastructure bias. Finds the authorization hole and the query that falls over at ten times the data.
backend · systems · integrations · infra
07 — How we engage
Product Build
Own a new product or a substantial area of one.
Workstream Ownership
We take ownership of a difficult product or technical area inside your team.
Technical Takeover
Audit and assume ownership of an inherited codebase.
Hardening Sprint
Short engagement on the biggest technical risks — starts with a two-week audit you keep either way.
- 01
Understand
Product, users, existing system.
- 02
Define
Scope, UX, architecture, approach.
- 03
Build
Short iterations, frequent releases.
- 04
Ship & improve
Deploy, monitor, keep improving.
08 — The first two weeks
Judge us on the work, not on our portfolio page.
We can’t show most of what we’ve built, so the start of an engagement is small, concrete and easy to walk away from.
Day 1–2
Technical deep-dive
A call on your codebase or your problem, in whatever depth you want. Architecture questions, not sales questions.
Week 1
Written assessment
Risks, priorities and a plan you own — useful even if you hand it to someone else.
Week 2
Something shipped
One real fix or feature in production, so you can judge the code rather than the pitch.
- Rolling monthly — no lock-in
- You keep every repo and document
- References on request
- We’ll sign your NDA first
Building something ambitious?
Tell us what you’re building, where it is today, and what’s in the way. If there’s a codebase involved, we’ll sign your NDA before we look at it.
Start here
Tell us about the project
A few questions about what you’re building and where it stands. Takes about two minutes.
- 01You send the details
- 02We reply within one business day
- 03Technical deep-dive call, NDA first if needed
or email hello@stajics.com