What does AI product consulting actually involve?
AI product consulting is senior engineering judgement applied to a decision you have to make: whether an architecture will hold, whether a codebase is worth keeping, whether an AI feature is feasible on your data. Onpolar delivers it as a written assessment with the evidence attached — and, where it helps, the commit that proves the point.
- Formats
- Review · audit · due diligence · fractional
- Shortest engagement
- One week, fixed scope
- Deliverable
- A written assessment, not a deck
- Who does it
- The principal engineer
The problem
You have been sold strategy before
The pattern is familiar. Weeks of workshops, a maturity model, a roadmap with three horizons, an invoice — and a team that still does not know whether their architecture survives ten times the load.
The questions that actually block decisions are technical, and they are answerable. Does this tenancy model hold at scale. Is this codebase worth keeping. Will this AI feature work on our data or only in the demo. Is the company we are acquiring selling us a product or a liability.
Answering those means reading the code and running the numbers, which is why we do it as engineers rather than as advisors. You get a written assessment with the evidence attached, and often a branch that demonstrates the fix instead of describing it.
What you get
What comes out of an engagement
A written assessment
Findings, evidence, severity and a recommendation you can forward to a board or an investor without translating it first.
Code, where code is the answer
A proof-of-concept branch, a benchmark, or the migration that demonstrates the recommendation. An untested opinion is not worth billing for.
Architecture review
Tenancy, data model, auth, scaling path and failure modes examined against where the product is actually going, not where it is today.
Security and dependency audit
Authentication, authorisation, secret handling, injection surface and dependency risk, ranked by what an attacker would reach for first.
Technical due diligence
For an acquisition or an investment: code health, key-person risk, licence exposure, and the real cost of the roadmap being promised.
A fractional principal engineer
A senior engineer in your standups, reviewing pull requests and owning the hard calls, for a defined number of days a month.
How it works
How an engagement runs
- 01Day 1
Scope the question
A short call to turn "we need advice" into a question that has an answer. If the question is not ours to answer, we say so before invoicing anything.
- 02Days 2–4
Read everything
Repository access, whatever architecture documentation exists, incident history, dashboards. The time goes into the code rather than into interviews about the code.
- 03Days 4–7
Test the claims
Benchmarks, load paths, and a proof-of-concept branch wherever feasibility is the actual question rather than a matter of opinion.
- 04Day 8
Deliver it and defend it
A written assessment, walked through live, evidence open. Your engineers should be able to argue with it — that is how you know it is real.
Proof of work
How this looks in production
The credential for judgement about production systems is having operated some. These two are ours — built in-house, running in production, with every decision and consequence that implies.
ERPFlow — API-First Multi-Tenant SaaS ERP with EU E-Invoicing
ERPFlow is a multi-tenant SaaS ERP — invoicing, CRM, inventory, staff and finance in one platform — built API-first on a Go + PostgreSQL backend behind a single OpenAPI contract, with native Peppol e-invoicing and per-seat Stripe billing.
Deal.ee — AI-Indexed Business Intelligence and Marketplace for Estonia
Deal.ee turns Estonia's public business data into a fast, AI-citable intelligence layer — ~368,000 companies across 19 government datasets, refreshed daily in Estonian, Russian and English — and adds a verified-company marketplace where businesses claim their profile by national eID, with an offers layer — products, services, real estate, jobs and investments — rolling out on top. Built in Go on PostgreSQL, engineered to be cited by ChatGPT, Claude, Perplexity and Gemini.
Have a decision that needs an engineer, not an opinion?
Bring the question. Thirty minutes is free, and a fair number of these get answered inside it.
Engagement formats
Four ways to buy senior judgement
Each is fixed-scope with a named deliverable and a date. Pick by the decision you are trying to make.
| Format | The question it answers | Duration and deliverable |
|---|---|---|
| Architecture review | Will this design hold as we grow, and what breaks first? | 1 week — written assessment with a ranked risk list and a scaling path |
| Code and security audit | Is this codebase safe, maintainable and worth keeping? | 1–2 weeks — findings ranked by severity, each with a reproduction |
| Technical due diligence | What are we actually buying, and what will it cost to own? | 1–2 weeks — report covering code health, key-person and licence risk |
| Fractional principal engineer | Who makes the hard calls while we hire? | Monthly — a set number of days, in your standups and your pull requests |
None of these is a retainer for availability. Every one has a deliverable with a date on it.
FAQ
Questions we get asked
How is this different from hiring a consultancy?
We read the code. The deliverable is an assessment with evidence and often a branch, produced by the engineer who would also build the fix if you wanted it built. There is no analyst layer between the person forming the opinion and the person who understands the system.
Who actually does the work?
The principal engineer. At this size that is arithmetic rather than a promise we invented — you are not being sold senior time and delivered junior time.
Can you do due diligence on a company we are acquiring?
Yes. Code health, architecture risk, key-person dependency, licence and dependency exposure, and an honest read on whether the roadmap being promised is achievable with the team being acquired. Delivered as a report your investment committee can actually use.
What if your recommendation is that we rebuild?
Then we say so, with the reasoning and the cost, and you are free to have somebody else do it. We have told clients a rescue would cost more than a rebuild and lost the follow-on work for it. An assessment you cannot trust is worth nothing.
Will you review AI-generated code?
Frequently. Prototypes out of Cursor, Lovable, Bolt, v0 or Replit tend to share the same findings: no migrations, permissive access rules, secrets reachable from the client, no indexes, no tests. The audit separates what is genuinely dangerous from what is merely untidy, so hardening gets scoped rather than guessed at.
How much access do you need?
Read access to the repository, whatever architecture documentation exists, and ideally dashboards and incident history. We can work from less, and the assessment will say plainly where we were guessing.
Is there a smaller version for a single decision?
A thirty-minute call is free and often enough. If the answer needs something read first, it becomes a scoped review — but plenty of questions get answered on the call, and we will not manufacture a project out of one.
Do you do the implementation afterwards?
If you want us to. The review is priced and delivered standalone so that it is useful either way, and it is deliberately not a sales document for a larger project.
Start with a question
Tell us the decision you are facing and what you can share. We reply within one business day.