Consulting
IT consulting and product audit
The most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
- Pricing
- From $680
- Timeline
- The express format takes about a week: two or three interviews, a high-level audit and a 10 to 15 page document with findings and an estimate. A full audit with code, architecture and analytics review plus a written specification runs 2 to 3 weeks. Large systems with multiple integrations take up to 4 weeks. A standalone 90 minute consultation is available separately.
A starting price. The total depends on scope, integrations and deadlines.
In short
IT consulting starts at ₽50,000 and takes 1 to 3 weeks. We interview the team and the product owner, review the code, architecture and metrics, write the technical specification, recommend a stack and produce a phased estimate of time and cost. You end up with a 20 to 40 page document you can take into a tender with any contractor, including ones that are not us.
When consulting should come before building
A few signals show that ordering development is premature. Contractor estimates differ by a factor of five or ten, which means each of them priced a different project. The team does not agree on what belongs in version one. The existing product works, but every new feature costs more than the last. Or there is an idea with no answer to how it differs from three similar services already on the market.
Consulting is not needed when you already have a detailed specification, a clear architecture and an experienced technical lead in house. In that case we say so rather than sell an audit for its own sake. But when the specification amounts to a messenger thread and a dozen screenshots of other people’s sites, a week spent on a document usually pays for itself the first time you compare quotes.
- Contractor quotes differ several times over and it is unclear which one is realistic.
- The product exists but technical debt is slowing every release.
- You need to decide whether to extend the current system or rebuild it.
- A developer is leaving and you need to know what you are actually inheriting.
- You need a defensible budget estimate for an investor or the board.
Technical audit: what we look at
The technical audit answers one question: what state the system is in and what it will cost to keep developing it. We read the code selectively but deliberately, focusing on entry points, the most frequently changed modules, anything touching money or personal data, and the integrations. Then we look at architecture, database schema, dependencies and how current they are, tests, the build and deploy pipeline, logging and monitoring.
We also check the things nobody asks about until it is too late: who holds access to the domain, hosting, repository and payment gateway; whether backups exist and have ever been restored; how many people understand the system end to end. A bus factor of one is as much a risk as a vulnerability in the code, and usually a more expensive one.
Baseline security is always in scope: password storage, API authorisation, input validation, secrets committed to the repository, HTTPS and headers, and how personal data is handled including local data residency requirements. This is not a penetration test, but roughly 80 percent of the usual problems surface at exactly this level.
Product audit: why the thing exists
A technically sound product can still be useless. The product half of the audit checks something else: who the user is and which job you solve for them, where they get stuck in the funnel, what the analytics show (and whether analytics were ever set up), which backlog items actually move money and which were added because someone suggested them. It often turns out half the planned development is unnecessary.
We run three to six interviews: the product owner, sales, support and where possible two actual users. Sales and support know more about the product than any dashboard, because they hear the same objections and the same questions every day, none of which the interface answers. Those conversations almost always change the backlog order.
The product section ends in a prioritised list: what pays off within the quarter, what can wait and what should be cut. Plus a check that basic analytics are in place at all, because without events and funnels the next iteration is another decision made blind.
The specification and the stack
Our specification is a working document of 20 to 40 pages, not a formality attached to a contract. It covers product goals and metrics, user roles, user journeys, functional requirements screen by screen, the data model, integrations and APIs, non-functional requirements (load, speed, security, personal data storage), admin panel requirements, acceptance criteria and an explicit out-of-scope section.
People underrate that last section, and it is the most useful one. The scope boundary is what protects both client and contractor from endless expansion. Once the exclusions are written down, an argument about whether something was included takes a minute to settle instead of a week of email.
We choose a stack against four criteria: the problem (load, real time, offline, data requirements), the team (who maintains this in a year and how easily such people are hired locally), total cost of ownership (hosting, licences, data residency rules) and the schedule. If a ready-made CMS or a low-code platform solves the problem, we say so plainly, even when that costs us the development contract.
- The specification is delivered in editable form so you can hand it to any contractor.
- Diagrams: architecture, data flows, integrations and role structure.
- A comparison of two or three stack options with trade-offs and cost of ownership.
- Acceptance criteria you can verify without being a developer.
Roadmap, estimate and what happens next
We estimate in ranges, not points: typically plus or minus 30 percent at the document stage, narrowing once design and integrations are worked through. A precise figure before work starts is either an undercut to win the tender or a large buffer baked into the price. The breakdown is phased so you can see what ships first and where to stop if the budget runs out.
The roadmap is organised around the first working release: what belongs in the MVP, what waits for the second phase and what is deferred until demand is confirmed. A risk register comes with it, listing integrations with unpredictable timelines, third-party dependencies and areas where requirements may shift, each with an impact estimate.
After that the choice is yours. You can continue with us or take the document to tender. We can help review the quotes that come back, ask contractors the right technical questions and sanity-check their delivery plan. That is a separate service, and it usually pays for itself in the gap between the first and third proposal.
What the work includes
- Technical audit report with findings ranked as critical, important or tolerable
- Product review: user journeys, funnel bottlenecks and a prioritised backlog
- A 20 to 40 page specification with acceptance criteria and explicit scope boundaries
- Architecture, data flow and integration diagrams
- A reasoned stack recommendation comparing two or three options by cost of ownership
- A phased time and budget estimate with ranges and the reasoning behind them
- A three to six month roadmap with a risk register
- Team and process review: where time is lost and what is missing in hiring and workflow
- A closing 60 to 90 minute session walking through the document and answering questions
How we work
- 01
Discovery
Days 1 to 4. Kickoff plus three to six interviews with the product owner, sales, support and engineering. We collect access, documents, analytics and the current contractor arrangements.
- 02
Audit
Days 5 to 10. Review of code, architecture, data, infrastructure and security, with the product track running in parallel across funnel, metrics and backlog. A mid-point call covers the first findings.
- 03
Decisions and specification
Days 8 to 15. We settle the stack, fix the architecture, write the specification and acceptance criteria and agree the scope of the first phase.
- 04
Estimate and roadmap
Days 15 to 20. We break the work into phases, estimate time and budget as ranges and assemble the risk register and a three to six month plan.
- 05
Handover
A closing session, handover of every document in editable form and, if needed, help reviewing the proposals contractors send back.
Technology and tools
- Miro
- Notion
- Figma
- Mermaid / PlantUML
- PostgreSQL
- Docker
- Sentry
- Lighthouse
- Яндекс.Метрика
- GA4
Selected work
NA Consulting
A website for the NA Consulting agency. An interactive landing page packs the full story of the agency and its services into a minimalist layout. Calm colours convey trust and professionalism. Built by Veltos.Tech together with Aliya (finnikkis.github.io/maulaviyevadesign).
Sber — Guardian of Truth
Checks GigaChat answers for factual hallucinations and returns a probability of invented facts — no external APIs or fine-tuning.
MOEX Alpha Autopilot
An autonomous MOEX trading system: analyses the market, validates ideas and places trades on the live exchange with strict risk controls.
Frequently asked questions
How much does IT consulting cost?
From ₽50,000 for the express format: two or three interviews, a high-level audit and a 10 to 15 page document with findings and an estimate, delivered in about a week. A full audit covering code, architecture and analytics plus a written specification takes 2 to 3 weeks and starts at ₽120,000. A standalone 90 minute consultation costs ₽15,000, and that amount is credited against the audit if you go ahead with one.
Why pay for an audit instead of going straight to development?
Because without a specification you cannot compare contractors. Three studios will quote ₽300,000, ₽900,000 and ₽2,500,000, and those are estimates for three different projects. The audit fixes the scope so you are comparing like with like. The second argument is rework: changing requirements in a document costs a fraction of changing them mid-build. If you already have a detailed spec and a clear architecture, you do not need consulting, and we will say so.
What goes into a technical specification?
Ours runs 20 to 40 pages: product goals and metrics, user roles, user journeys, functional requirements screen by screen, the data model, integrations and APIs, non-functional requirements covering load, speed, security and personal data storage, admin panel requirements, acceptance criteria and a section on what is explicitly out of scope. That last section matters just as much, because it protects both you and the contractor from endless scope expansion.
Should we rebuild from scratch or extend what we have?
The default answer is extend. A rewrite almost always costs more and takes longer than expected, and a working system holds accumulated logic nobody remembers writing. A rebuild is justified when three conditions line up: the technology is unsupported or unhirable, the cost of each new feature grows release over release, and the product has hit a ceiling on load or security. The middle path is moving parts into a new stack gradually without stopping the business.
How do you choose the technology stack?
Against four criteria: the problem (load, real time, offline use, data requirements), the team (who maintains it in a year and how easily such developers are hired), total cost of ownership (hosting, licences, data residency rules) and the schedule. We do not pick a stack to match our own preferences. If a ready-made CMS or a low-code platform solves it, we say so directly, even when that means losing a large development contract.
Can we use your specification with a different contractor?
Yes. The document is yours and comes in editable form together with the diagrams and the estimate. That is the most common way it gets used: you send the spec to three or four studios and compare proposals for identical scope. We can help at that stage by reviewing the quotes, putting the right technical questions to each contractor and checking their delivery plan. It is a separate service that usually pays for itself in the price gap between proposals.
Want to talk it through?
Tell us what needs building. We will work through the task, propose an approach and send a staged estimate. No charge, no commitment.
Related services
- Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.
- Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.
- Website support and improvementNot every project needs a rewrite. It is often cheaper to fix the speed, clear the technical SEO errors, add the missing sections and integrations, and end up with a working site without paying for a new build.
- UX/UI design for websites and appsWe design interfaces that survive contact with production: research, structure, UI kit and a clean handoff to the developers. Everything lives in Figma as components with real states and real breakpoints, not as a folder of flat mockups. The same process covers landing pages, corporate sites, e-commerce, web apps and mobile.
Terms used on this page
- Russian personal data law (152-FZ)152-FZ is the Russian personal data law: it requires that data on Russian citizens be collected in databases located in Russia, that the regulator be notified of processing, that consent be obtained separately, and that any breach be reported within 24 hours.
- Outsourcing vs in-houseOutsourcing and in-house are two ways to cover a development need: contract an external team at an agreed hourly rate, or build a staff team where salaries come with payroll taxes, recruitment, equipment and management on top.
- Software import substitutionSoftware import substitution means moving information systems onto Russian products listed in the state software registry: for public sector customers and critical infrastructure operators it is a legal requirement, and for other businesses it is a condition of tender access and a way to remove vendor abandonment risk.
- Legacy codeLegacy code is working code that is expensive to change: it runs on an outdated stack, has no test coverage or has lost its authors, so every edit means reconstructing the logic from the source and risks breaking something unrelated.
- MicroservicesMicroservices are an architecture in which an application is split into several independent services, each with its own data and release cycle: they talk over the network through APIs, deploy separately and scale individually, but they demand mature infrastructure.
- MonolithA monolith is an application built and deployed as a single unit: all the code lives in one repository, runs in one process and works against one database, releasing as a whole, which buys simplicity at the cost of coupling.
Further reading
- The Technical Specification: Structure, a Worked Template and the Usual MistakesA specification is not bureaucracy, it is leverage: anything that does not match it gets fixed by the vendor at no charge. Here is the section structure, a filled-in example for a corporate site and how to write acceptance criteria somebody can actually test.
- How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.
- Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.