5 questions a CTO should ask a blockchain contractor before starting a project

The blockchain development market is oversaturated with teams offering the same thing. Behind identical presentations, tables, and grandiose statements often lies weak expertise. CTOs have to figure out who is capable of bringing a product to production and who only knows fancy terms.

The problem is that most standard questions do not provide the necessary depth. Any contractor can confidently talk about smart contracts, “understanding Web3,” and knowledge of Solidity. This says nothing about how they will cope with architecture under load, integration with the client’s existing system, or scaling the product in the future.

To separate strong performers from those who work superficially, you need questions that reveal a real approach to architecture, security, and data handling. Below are five questions that we have identified over three years of working in blockchain development and that help you understand how ready a contractor is to lead a product.

1. Why are you proposing this particular protocol?

This is a simple question that is rarely asked correctly. Contractors often choose a network out of habit or because “everyone else does it.” This approach leads to problems: increased fees, insufficient bandwidth, lack of necessary privacy mechanisms, or the inability to update logic without migrations.

It is important for the CTO to hear arguments based on the requirements of a specific project.
The team must consider:

• the load and frequency of operations;
• the cost of transactions when scaling;
• support for private data or authorized participants;
• confirmation speed requirements;
• future integrations and scalability.

If a contractor relies on one or two familiar blockchains and promotes them regardless of context, this is a sign of a template approach. “Ethereum is popular” is not an argument. The same applies to phrases about Solana, Polygon, or any other network without specifics.

An experienced team explains the difference between protocols through practical consequences: how the selected network will behave with 5, 50, and 500 thousand users; what limitations its mechanisms impose; how the load is processed; what will happen when competition in the mempool increases; whether the architecture can be adapted without a complete overhaul.

When designing Red Rock Pool e had to consider requirements for throughput, latency, and network stability. The choice of protocol and architecture was not obvious: some data had to be processed instantly, some had to be recorded on the blockchain, and some had to be stored off-chain, but with full integrity checks. This experience helps us better understand the trade-offs between networks when we discuss the architecture of future customer products.

2. What is your experience in integrating blockchain with existing company systems?

Blockchain products rarely exist separately from the rest of a company’s infrastructure. They have to work alongside CRM, accounting modules, financial systems, warehouse databases, and internal services. Setting up such a connection is much more difficult than writing a separate smart contract.

However, many contractors perceive blockchain interaction with other systems as a task that should be solved by the client. This approach later leads to product malfunction: data discrepancies, lost events, and processes that become dependent on manual actions.

If the team avoids the topic of integration, this is a warning sign. Good developers talk about how they solved similar problems:

• synchronizing transactions with 1C, SAP, or custom ERP;
• working with queues when events from the blockchain arrive faster than the backend can process them;
• soft recovery after an RPC or node failure;
• specific cases where network latency disrupted business processes and how they were fixed.

Integration cannot be reduced to simply transferring data from one system to another. In reality, you have to take into account delays between services, situations where data arrives in different orders, repetitive events, and moments when the blockchain changes the sequence of blocks, causing some of the information to be temporarily incorrect.

The contractor must explain how they solved such problems in previous projects. What mechanisms did they use to keep the system running if one of the data sources became unavailable? How did they ensure that operations were not performed twice? What problems did they encounter during integration, how did they manifest themselves, and how did the team fix them?

3. What is your disaster recovery strategy?

Sometimes it seems that if logic is transferred to blockchain, the system becomes completely stable. In practice, this is not the case. Failures occur at the level of RPC providers, cloud infrastructure, databases, services that process events, and even queues between modules. The network itself may continue to operate, while the product may temporarily lose functionality or return incorrect data.

The CTO needs to understand how well the contractor can design a system so that it recovers from failures.

A strong team talks about:

• backup nodes in different regions;
• mechanisms for quickly switching between providers;
• clear RPOs and RTOs — not abstract, but measurable;
• monitoring of contracts, transactions, and infrastructure;
• emergency scenarios, including temporary suspension of operations.

With our experience, we know exactly how to act in critical situations. For example, what happens if one of the modules starts returning outdated data or delays events. Can operations be temporarily blocked? How are users notified? How are data conflicts resolved after recovery?
We understand that failures are inevitable in complex systems, and we know how to work with them so that the product remains manageable and predictable.

4. How smart contracts are audited and what is included in the verification process

Smart contracts require particularly careful verification because errors in them cannot be corrected with a regular update. Even minor flaws in logic can lead to product malfunction or incorrect processing of transactions. Therefore, it is important for the CTO to understand how the contractor organizes quality control and what stages the contracts go through before release.

An experienced team describes the sequence of actions: how internal checks are performed, how logic is analyzed, how non-standard scenarios are tested, and what is considered a readiness criterion. This approach demonstrates the level of maturity much better than listing individual tools.

At this point, the contractor usually specifies:

• how code reviews are conducted within the team;
• what cases are checked in addition to standard scenarios;
• how static analysis tools such as Slither and Mythril are used;
• which parts of the logic are modeled manually and which are checked automatically;
• how the interaction of several contracts is tested.

If the contractor limits themselves to a general statement that testing is carried out within the team, this indicates that there is no comprehensive process in place. External code testing is considered standard practice, especially in products that process user funds or use complex distribution logic. An experienced team does not shy away from independent testing and includes it in the work plan in advance. This approach significantly reduces the risk of errors and makes the system’s behavior more predictable.

5. How do you work with compliance and regulatory restrictions?

This point is often underestimated. Many believe that legal issues are the client’s responsibility. In practice, any blockchain system faces regulatory requirements much earlier than it seems: storage of personal data, validity of transactions, compliance with local cryptography standards, mechanisms for confirming user actions.

The contractor must understand how to make the product legally transparent without violating the logic of the blockchain. This does not mean that developers are required to be lawyers, but they must know how to properly transfer data to the on-chain layer and what risks arise if the project ignores regulatory requirements.

Signs of competence:

• accurate handling of personal data and logs;
• correct recording of events via on-chain hashes;
• understanding of industry requirements if the project is related to finance or identification;
• interaction with the client’s lawyers when designing the architecture;
• ability to explain what can be stored on the blockchain and what should remain outside it.

When a contractor calmly discusses this topic and does not try to brush it off with a phrase like “we’ll figure it out later,” working with them becomes predictable.

Conclusion

No in-depth investigation is required to evaluate a contractor. These five questions and careful attention to how the team justifies its decisions are sufficient.

Strong specialists:

• respond without making excessive promises;
• link technical solutions to real limitations;
• are not afraid to discuss failures and mistakes;
• draw on their experience and demonstrate what they have learned from previous projects;
• offer not only tools, but also processes.

Weak contractors speak vaguely and avoid specific examples. In such cases, it is enough to ask to see working code or the results of previous projects — this immediately makes the picture clear.

These questions help to identify the level of the team even before development begins. They make it easier to choose partners who are capable not only of bringing the product to production, but also of ensuring stable operation and further development.

If your project requires neat architecture, reliable smart contracts, and smooth infrastructure, you can discuss the task with the Nomium team. We have implemented more than 10 blockchain projects and understand well how to bring an idea to stable production.