Victor Slompo
I run product strategy, and I build.
Fifteen years in digital products. For the past three I've been building AI-first across six unrelated domains — four of them shipped to real users, most starting as solo builds before being handed to a squad. What I know best is the part after launch, where shipping turns out not to be the same as adoption.
Three habits that show up in everything I've built.
I separate what a system calculates from what a model asserts
An LLM will happily return a number that looks like a statistic with nothing behind it, and the interface renders it identically to one the code computed. In my own SaaS I classified every figure as calculated, model opinion, or placeholder, and kept an audited defect log referenced to file and line. I once documented that a panel labelled “correlation engine” computed no correlation at all — a high-severity defect against my own work.
I build the thing instead of writing another document
When a spec is ambiguous, a working prototype settles the argument faster than three more paragraphs. The exception is a fact I can't invent: on a Revit automation for sanitation engineering I stopped building and sent fifty-one numbered questions, because no prototype tells you the volume of a receiving chamber. Next.js, Supabase, Vercel, Postgres, LLM APIs, C# when the domain demands it, Claude Code daily. Enough to put something real in front of engineering or a customer within days — and enough to make feasibility conversations a discussion rather than a handover.
I ship narrower than what was asked for, when the evidence says so
Commercial at a marketplace once asked me for a pricing engine. The data showed the effect was concentrated in a few categories and absent elsewhere; partner interviews showed the bigger pain was manual effort. I shipped something smaller, aimed at removing roughly 70% of that effort, and validated with a small group before committing the full build.
These are the questions I'd ask about any AI project — including yours.
Six builds, six unrelated domains. Mostly built alone.
AskMoses.AI
Conversation intelligence for sales teams. Transcribes every call and scores it against the client's own playbook — not a generic template — returning written feedback per section of the conversation. I defined the product, built the MVP end to end, then led the squad that scaled it.
Multi-tenant · 3 access roles · 3 plans · usage-based billing · LLM scoring · GoHighLevel CRM ingestion
Of those 17 signed organisations, only 6 ever generated usage. Eleven never activated — the onboarding asked people to connect a CRM and configure a rubric before returning any value. I found it going account by account; the aggregate looked fine. It changed how I design first-run experiences, and it's the reason I don't treat “shipped” as a finish line.
Integrated Report 2025 — GEO
A corporate sustainability report rebuilt to be read and cited accurately by language models, not just indexed by search engines. Server-rendered so crawlers get real HTML, with structured data, an llms.txt generated from the same source of truth as the visible pages, and separate routing for humans and bots. Trilingual, accessible, and reviewed figure by figure against the official report.
Next.js (App Router) · Schema.org / JSON-LD · llms.txt · dynamic sitemap · Vercel
I didn't want to claim it worked, so I instrumented it. A log collector separates fetches triggered by a real user question from autonomous training and indexing crawls, and tracks citations that converted into visits. Most GEO work sells a narrative; this one has a measurement behind it.
Freedom Marine
Configure-price-quote for a Canadian yacht dealer, replacing spreadsheet-based quoting. Multi-brand catalogue, engine options and add-ons, live FX conversion refreshed hourly with a cache fallback, and an admin panel that lets the commercial team maintain models and pricing policy without going through engineering. Quotes push straight into HubSpot.
Next.js · Supabase · live EUR/USD → CAD rates · HubSpot integration
Enterprise agent platform
A multi-agent architecture running Legal and Sales business processes autonomously, with human review at defined checkpoints. LLM orchestration, context engineering, external tool use, and integration with corporate APIs and data. Running continuously in production on AWS.
LLM orchestration · MCP (Google Workspace, Miro, GitHub) · RAG over corporate data · AWS · Cloudflare Access
Quality-gate validators, a replay buffer, a frozen research document, and the discipline of independently verifying what the agent reports about itself. I caught the system inflating its own metrics and issuing overconfident diagnoses more than once — which is the reason the verification exists at all.
Revit automation — pumping stations
A Revit add-in that generates the model of a sewage pumping station from topography, a 2D layout and a parameter file — terrain, units, diameters and connected pipes. The same code runs two ways: inside the engineer's Revit, and headless in the cloud through Autodesk Design Automation. The engine itself runs and is tested without Revit installed at all.
.NET 10 · Revit 2027 API · Autodesk APS Design Automation · C# · CI on Windows
Whatever cannot move correctly stops, with a warning naming why, and no connection is ever left loose. Ten situations where that happens are catalogued rather than quietly handled. When Revit raises an error mid-operation, the whole operation is undone — because Revit's own default resolution can silently drop a constraint.
Counter assistant — catalogue search
A messaging assistant for a builders' merchant: 13,312 products from the ERP spreadsheet, searched in 1–5ms by an inverted index held in memory. No database, no embeddings, no vector store. The language model never sees the catalogue — it receives eight results and writes the reply. Run with the owner to find out where an assistant like this actually breaks.
Python · Inverted index in memory · Typed measure filter · Counter-vernacular synonym layer · Tool-calling agent
Taking the model out of retrieval fixed retrieval: the search does not return the wrong product. The surface that was left — writing the reply — still invented. It stated specifications the catalogue does not hold, read a product's "4 stages" as four horsepower, and confirmed a product the shop does not stock before searching for it. In a shop, a sentence like that is an offer. That finding is the deliverable.
Marketplace and regulated finance, where the numbers came from.
Retail E/commerce Luxuxy
Global fashion marketplace, Europe & US
- Unified Shopify, WooCommerce and Adyen under a single integration layer, removing the technical barrier to acquiring sellers
- Rebuilt partner onboarding into a shared capability used by commercial, operations and engineering — time-to-live from weeks to days
- Assisted pricing that removed ~70% of manual pricing work
- Automated catalogue quality checks: time-to-shelf down 40%
Sistemas Cooperativos Brasileiros
Financial institution under regulatory supervision
- Launched and scaled digital credit: 25% monthly conversion on approvals, replacing a branch-based process
- Automated approval that cut customer waiting time by 40%, with risk and compliance intact
- Created the product operating model adopted across departments — DOR/DOD criteria, Scrum, Kanban, Flight Levels and SAFe integrated so teams stopped renegotiating process
- Ran an 80-hour technical mentoring programme for POs and tech leads
I treat documentation as a deliverable, not an afterthought.
Two artefacts I can share on request, because they say more about how I work than a CV does.
System manual — AskMoses.AI
How every number in the product is derived, classified as calculated, model opinion, or placeholder. Includes an audited list of known defects referenced to file and line, and an explicit separation between intended trade-offs and genuine bugs — including the ones that are mine.
Working notes — operating agents from the terminal
A write-up of my own practice running production agents: patching files by content with assertion guards instead of line numbers, validating config before a restart, debugging an OAuth flow from first principles, and the rule I keep coming back to — two passing validations are not proof.
When the work is bigger than one person.
Some of what I've built started solo and ended up with a squad — a PO, a tech lead, engineers. VS Solutions is how I take on that kind of scope: a small team I work with on client projects, where I stay on product and architecture rather than handing it over.
If you're weighing whether something needs one person or a team, that's a conversation worth having before anyone writes a spec.
Happy to talk about what's actually feasible.
Whether that's a role, a project, or twenty minutes as a sounding board on something you're considering building. I'll tell you when AI isn't the answer — that's usually the more useful conversation.
Based in Florianópolis, Brazil. I work remotely with distributed teams across Europe and the US, and have for the past three years.