A product users can log into
Auth, roles, and data boundaries land before the fancy AI layer. You get a real app with accounts, not a public demo that breaks the first time someone shares the link.
Most AI projects stall after the prototype. You need someone who can take the idea from prompt to production: structured outputs, auth, billing, logging, cost controls, and a codebase your team can maintain. I do AI product development that ships.
80+ five-star reviews · 100% Upwork Job Success · 120+ projects
Zlatko MarjanovicDigital strategist & creative director



Three outcomes I hold myself to before anything ships. If these are not the job, this is the wrong page.
Auth, roles, and data boundaries land before the fancy AI layer. You get a real app with accounts, not a public demo that breaks the first time someone shares the link.
Structured outputs, fallbacks, rate limits, and logging so a bad model response does not corrupt data or burn your API budget overnight.
The same person who scopes the product can build the Next.js app, wire Stripe, set up Supabase RLS, and keep shipping after go-live.
Scope first, so you know what you are buying and what stays out.
I help founders and product teams turn an AI idea, a Lovable prototype, or a half-built agent into software that runs in production. That means architecture, the core product loop, integrations, and the boring infrastructure that keeps it online.
Teams with a clear use case and users waiting, but no one on staff who can own the full stack. If you still need to validate the idea, start with digital strategy. If the prototype works in a demo and dies in real usage, this is the right brief.
Customer-facing AI SaaS, internal copilots, agent workflows with human checkpoints, API integrations with OpenAI, Claude, or Gemini, and the admin tools to monitor what the system is doing. Stack is usually Next.js, TypeScript, Supabase or PostgreSQL, Stripe, and Vercel.
AI application development is not prompt engineering in a vacuum. Production means idempotent webhooks, eval hooks, cost caps, error states, and a deployment pipeline. I take inherited Bolt, v0, or Cursor builds and harden them instead of starting from zero when the prototype is already close.
A dev shop will build whatever is in the ticket. An AI product engineer decides what should be deterministic, what should call a model, and where a human has to stay in the loop. That judgment is most of the value in AI product development.
Same order every time. Discovery, the plan, the build, then the check after launch.
We map the user job, the data the model needs, and what has to stay outside the LLM. That kills half the features that would have become maintenance debt.
Product scope, stack decision, and risk list
Auth, database schema, and the main workflow ship first. The AI layer sits on top of a working app, not the other way around.
Working staging environment with real accounts
Structured outputs, retries, logging, and admin visibility. We test failure modes before launch, not after a user finds them.
Production-ready AI paths with monitoring
Deploy, watch usage and cost, fix the friction that only shows up with real traffic. I stay on for the first production issues instead of disappearing at handoff.
Live product plus a backlog ranked by user impact
Every review is public and verifiable on
The artifacts you keep after the call, the build, or the audit.
What ships in v1, what waits, and what never should have been an AI feature in the first place.
Next.js or your chosen stack, typed, deployed, and documented enough that another engineer can pick it up.
Supabase auth, Stripe subscriptions or usage billing, and RLS or role checks where customer data is involved.
Prompts, structured outputs, fallbacks, and cost controls wired into the product, not pasted into a notebook.
Logs, error tracking, and internal views so you can see what the system did when something looks wrong.
Deployment, smoke tests, and the first round of fixes after real users hit the product.
Short answers so you can tell if this is the right engagement.
No. A lot of my work is taking an existing Lovable, Bolt, or v0 prototype and making it production-ready: auth, database, billing, error handling, and deployment.
OpenAI, Claude, and Gemini depending on the task. For orchestration I use n8n or code-first workflows in TypeScript. The model is a component, not the whole architecture.
Yes. New features, copilots, internal tools, and agent workflows that sit next to your current stack. I read the codebase first and ship the smallest useful slice.
Not as a standalone engagement. Prompts matter, but AI product development is the app around them: data, auth, UX for failure states, and ops. Prompt-only work does not survive contact with users.
Structured outputs, caching where it helps, rate limits, fallbacks, and logging. We set cost expectations before launch and wire alerts so a traffic spike does not surprise you on the API bill.
Next.js, TypeScript, Supabase or PostgreSQL, Stripe, Vercel. I match your stack when the product already exists. The goal is software your team can maintain, not a pile of no-code glue.
A focused v1 with one core workflow is often three to six weeks. Inherited prototypes can move faster. Scope always depends on auth, billing, and how messy the data model is.
Yes, on retainer or project basis. The first month in production always surfaces edge cases. I would rather fix them with you than hand you a demo and disappear.
AI product development is building software where AI is part of the user experience, with the same production standards as any other app: accounts, data, billing, monitoring, and a codebase that can evolve.
You work with one AI product engineer who scopes, builds, and ships. No handoff between a strategist, a prompt person, and a dev team that never talked to your users.
Same person, same commercial standard. Different entry point.
Most teams do not need another workshop deck. They need a digital strategist who can say what the site is for, what to build first, and what can wait. I do digital strategy consulting that stays connected to design and website development, so the plan does not die in a PDF.
A redesign fails when it starts in Figma. Website redesign services should start with website strategy, the pages that create pipeline, then website design and website development. I run that sequence so a custom website redesign does not erase the rankings you already have.
I work as an SEO consultant on the parts that actually move a site: crawlability, indexation, site architecture, schema, page quality, and the SEO risk inside a website redesign. SEO consulting services here are technical and implementation-heavy. If you need 40 blog posts a month, that is a different hire.
CRO is not a heatmap subscription. If the offer is unclear, the page asks for the wrong action, or the website redesign never defined a job for each URL, tests will not save it. Conversion rate optimization consulting starts with the offer and the page job, then I change the page.