Technical consulting before development starts
We review your technical problem, explain the options and help you make a decision before you spend money on development. A consultation is an engineering review of your question within an agreed scope: options, trade-offs, risks and concrete next steps.
- Stack
- Architecture
- Decision
What is a technical consultation and when do you need one?
A technical consultation is a paid review of a specific engineering question: choosing a stack, shaping an MVP architecture, checking a spec, or diagnosing a problem in a live product. An engineer studies the context you provide and explains the options, their trade-offs and risks; the outcome is a decision or a list of what still needs to be found out, plus 3–7 next actions. A consultation does not review the whole codebase — that is what an audit is for.
Who it is for
Founders without a technical partner
A vendor proposes a stack, an architecture and an estimate, and there is no one to check the reasoning with. We go through the proposal before you sign and help you frame the questions worth asking.
Teams before their first release
Architecture decisions are cheapest to change before features and user data are built on top of them. We help you decide what to put in place now and what to defer on purpose.
Developers building with an AI assistant
You shipped an MVP quickly with Cursor, Claude Code or Lovable — that is a real result. We help you understand the project structure, data and access so you can keep building with confidence.
Products with a specific problem
Something is slow, crashes or breaks after releases, and it is unclear where to start. A diagnostic session narrows down the causes before you pay for fixes.
Questions we help with
Which stack should we choose for our product?
We compare two or three realistic options against your problem, your team and the hiring market: speed to first release, cost of ownership, ecosystem maturity, vendor lock-in. The goal is not the trendiest stack but one your team can actually maintain.
Monolith or microservices — where should we start?
For most MVPs a modular monolith with explicit module boundaries makes more sense, but there are exceptions: separate teams, different scaling needs, regulatory constraints. We look at your case and at the conditions under which the decision should be revisited.
Are our spec and roadmap realistic?
A review surfaces missing roles and scenarios, non-obvious dependencies between tasks, and what can be moved out of the first release. You get prioritized comments and questions for whoever will build it.
The product is unstable — where do we look for the cause?
From symptoms, logs and metrics without personal data we build hypotheses and an order for checking them. If the answer requires reading the whole codebase, we say so directly and suggest an audit instead of guessing.
Our vendor wants to rewrite everything — should we agree?
Sometimes a rewrite is justified; more often replacing modules step by step is cheaper and safer. We go through the vendor's arguments, the risks of both paths and the data you need to decide.
What a consultation includes
items
- Review of the materials you share: the question, context, documents, safe code fragments
- A session with an engineer: clarifying constraints and working through the question
- Options and their trade-offs: timelines, cost of ownership, hiring, risks
- Risks and unknowns — what cannot be decided without more information
- A recommendation, or the conditions under which the choice changes
- 3–7 concrete next actions
- A written record of the outcome — by agreement, format settled in advance
Free intro call vs paid consultation — what is the difference
We keep them separate on purpose. Engineering advice given without studying the context can do harm, so the free call is for choosing how to work together, and recommendations come in the consultation.
| Aspect | Free intro call | Paid technical consultation |
|---|---|---|
| Purpose | Understand the problem and choose the right format | Get an engineering review of your question |
| What we need | A short description of the problem — no code, passwords or confidential documents | The question, context, documents and safe fragments |
| What happens | We clarify the problem, the product stage and your expectations | An engineer studies the materials and works through options, trade-offs and risks |
| Outcome | A next step — consultation, audit, mentorship or development — and a proposal | A decision or flagged unknowns, plus 3–7 next actions |
| Not included | Code analysis, engineering recommendations, a roadmap | A full audit, writing code, making the decision for you |
| Cost | Free | Defined after the brief and once the scope is agreed |
Consultation formats
We choose the format on the intro call based on your question, not on a price list. One question may need a combination of formats.
Stack and architecture
You are choosing technologies or the product structure before development starts.
- A comparison of two or three stack options for your problem and team
- Module boundaries, data model, integrations
- Risks of each choice: hiring, cost of ownership, vendor lock-in
Outcome: a recommendation or the conditions for choosing, plus next steps.
Diagnostic session
The product has a specific problem: crashes, slowness, errors after releases.
- Review of symptoms, logs and metrics without personal data
- Hypotheses about the cause and the order to check them
- What your team can check on its own
Outcome: a diagnostic plan and signs that an audit is needed.
Fixing the problem is separate work under its own agreement.
Spec, roadmap or backlog review
The document exists, but it is unclear how realistic it is.
- Missing roles, scenarios and non-functional requirements
- Technical dependencies and task order
- What can be moved out of the first release
Outcome: prioritized comments and questions for whoever will build it.
MVP architecture
You are preparing the first release and do not want to rebuild its foundation at the next stage.
- A minimal architecture for testing the hypothesis
- What to set up now: roles, data, environments, deployment
- What to defer on purpose and when to come back to it
Outcome: a first-release outline and a list of deferred decisions.
For developers using an AI assistant
The product was built with Cursor, Claude Code, Lovable or Bolt, and you want to keep developing it with confidence.
- A walk-through of the project structure and the decisions the assistant made
- Where risks usually hide: access, secrets, data
- How to brief the assistant and verify its output
Outcome: improvement priorities and signs that it is time for an audit.
A line-by-line code review is the AI-built MVP audit.
Session with founder and team
Business and engineering need to agree on a technical direction together.
- A shared picture of the product that both business and developers understand
- Working through contested decisions with each side's arguments
- Next steps with named owners
Outcome: a shared decision or a list of questions still to close.
Cost is defined after the brief and once the scope is agreed. Session length and format are tailored to your question.
What a consultation covers — and what it does not
Included
- One question or several related ones, within the agreed scope
- Review of shared documents, diagrams and safe code fragments
- Options, trade-offs and risks — explained so non-developers can follow
- Flagged unknowns: what needs to be found out before deciding
- 3–7 next actions
- A written record of the outcome — if agreed in advance
Not included
- A full code and architecture audit — that is a separate service
- Writing or fixing code
- Making the decision for you: the decision and accountability for it stay with the product owner
- Security testing, penetration testing, standards compliance
- Legal, tax or investment conclusions
- Access to production, passwords or keys — we do not ask for them
If answering requires studying the whole codebase, we will say so and suggest an audit — before you pay for a consultation that would not solve the problem.
How to prepare
You do not need to produce new documents — the more specific the question and context, the more useful the review.
- 01
State the question
One or two sentences about the decision you need to make. “Which stack should we use” is weaker than “Next.js with Supabase or a separate backend, if we need a mobile app next year”.
- 02
Describe the context
Product stage, users, who is on the team, budget limits and deadlines the business has already set.
- 03
Gather what you already have
Spec, diagrams, backlog, a vendor's proposal, code or log fragments — without passwords, keys or personal data.
- 04
List the constraints
What cannot change, which options you have already considered and why you dropped them.
- 05
Decide who joins
Who from the team will attend and who makes the final call — this shapes the language we use to discuss the question.
Do not send passwords, access keys or private code through the website form. We agree on how to share materials separately; an NDA can be signed on your template or InterLAB's.
Consultation or audit — which one do you need
A consultation answers “what should we do”; an audit answers “what state is the product in”. If you are not sure, start with the free intro call.
| Aspect | Technical consultation | Technical audit | AI-built MVP audit |
|---|---|---|---|
| Input | Question, context, documents and safe fragments | Agreed scope, read-only repository access, documentation | Code, role model, data schema, release context |
| Depth | Options and risks within the question | Planned, evidence-based review of code and architecture by domain | Access and roles, secrets, data, API, tests, build and deployment — within the agreed scope |
| Outcome | A decision or unknowns, plus 3–7 next actions | Owner summary, evidence-backed findings, roadmap | Risk map and a keep / fix / replace decision per module |
| Choose it when | You need to make a decision: stack, architecture, assessing a vendor's proposal | You need the real state of the product before growth, a vendor change or a deal | The product was built with an AI assistant and is about to face real users or payments |
If you need an audit
Demonstration sample: Consultation Summary
This is what a written record of the outcome looks like when one is agreed. The product, team and data are fictional: “TutorDemo”, a tutoring marketplace, MVP on Next.js and Supabase, one developer, about to add payments.
| Section | Content |
|---|---|
| Context | The MVP was built with an AI assistant and has its first users. Next step: online payment for lessons. Question: stay on the current stack, or move the backend into a separate service before adding payments. |
| Options | A — keep Next.js and Supabase and tidy up the modules. B — a separate NestJS backend now. C — keep the stack and handle payments in an isolated server-side webhook handler. |
| Trade-offs | A is the fastest, but data security rests on access rules (RLS) nobody has reviewed. B gives more control but means rewriting auth and the data layer, delaying payments. C isolates money flows and adds a handler plus its tests. |
| Decision | Option A with an element of C: keep the stack; payments go only through a server-side handler that verifies the provider's signature. |
| Unknowns | The payment provider is not chosen. Access rules on the bookings tables have not been reviewed — outside the consultation scope. The number of tutors at launch is not defined. |
| Action 1 | Describe the roles (student, tutor, admin) and each role's permissions in a single table. |
| Action 2 | Review access rules on bookings and payments — in-house or as an Express audit of that area. |
| Action 3 | Choose a payment provider and read its webhook requirements. |
| Action 4 | Make payment handling idempotent: a repeated notification must not create a second payment. |
| Action 5 | Add an end-to-end test for “booking → payment → cancellation”. |
| Revisit | Return to option B once a second client app (for example, mobile) appears. |
Demonstration sample. The company, product and data are fictional. A written summary is prepared by agreement — we settle the format before the consultation.
Do some groundwork before the consultation
Free tools and materials from the “How to build” library help you frame the question more precisely.
How a consultation works
- 01
Request and intro call
Free. We understand the question and the product stage and choose a format: consultation, audit, mentorship or something else.
- 02
Scope and cost
We agree on the question, participants, materials and how the outcome is recorded, including whether a written summary is needed. Cost is defined after the brief and once the scope is agreed.
- 03
Preparation
We study the materials and, if needed, send clarifying questions in advance so the session goes into analysis rather than retelling.
- 04
Session
We work through options, trade-offs and risks, explained so that both business and developers can discuss the decision.
- 05
Outcome and next steps
A decision or flagged unknowns and 3–7 actions. If an audit or ongoing mentorship makes sense, that is a separate proposal, not a required next step.
Get your project assessed before development starts
Describe the task in the form below — we reply within a business hour and suggest the next step: a call, a review or an estimate.
What we consult on
Questions that are cheaper to settle on paper than in code: technology choice, module boundaries, data, access, and the path code takes from developer to users.
- Stack choice
- MVP architecture
- Modular monolith and services
- Data model
- APIs and integrations
- Roles and access
- Environments and deployment
- Tests and releases
Materials we work with
Documents you already have are fine. A description and safe fragments are usually enough, and logs should contain no personal data. A consultation rarely needs repository or production access.
Specs, Roadmap, Backlog, Diagrams, DB schema, API docs, Code fragments, Vendor proposal
Technical consulting FAQ
Yes. Its purpose is to understand the problem and choose a format. We do not give engineering recommendations on it: advice without studying the context would be a guess, and a guess is worse than no advice.
Cost is defined after the brief and once the scope is agreed. Length depends on the question and format — we agree on that in advance as well, before payment.
By agreement, we record the outcome in writing: context, options, trade-offs, decision and unknowns, next actions. Whether you need such a document is settled when we agree on scope; see the demonstration sample above.
Usually not: a description and safe fragments are enough. If the answer requires studying the whole codebase, that is an audit, and we will say so. Do not send passwords, keys or personal data; we sign an NDA on your template or InterLAB's.
If the question is how to develop the product further, a consultation. If the product already takes payments or stores user data and you are unsure about access and data rules, the AI-built MVP audit. Not sure — start with the free intro call.
No. A consultation is a standalone service: your own team or any vendor can carry out the next steps.
Deep dives in the blog
Related services
Start with a free call about the format
Describe your question in the form or on WhatsApp. On the intro call we will understand the problem and suggest a format. The engineering review happens in the paid consultation; scope and cost are agreed after the brief.
- The first short conversation is free — we choose the format
- NDA — yours or ours
- Pricing after a brief and an agreed scope