Vendor proposals all look the same. Polished decks, confident timelines, impressive logo walls. The thing that actually separates a partner who'll ship a production system from one who'll hand you a liability isn't in the proposal — it's in how they answer direct questions.
Here are the questions worth asking, grouped by what they reveal, along with what a strong answer sounds like and what should make you walk.
Security and audit
Can you show me an audit report from a comparable project? Not "we take security seriously" — an actual report. Strong answer: they share redacted reports, walk you through findings, and explain how each was resolved and re-reviewed. 🚩 Red flag: no third-party audit practice at all, or audits treated as an optional add-on you can decline to save money.
Exactly how do you store private keys and deployment secrets? This is the single highest-value question in the list. Strong answer: specific, confident detail — secrets managers, hardware or multi-sig for production signing, environment separation, and controlled access. 🚩 Red flag: vagueness, or anything resembling keys in plaintext config files or secrets shared over email or chat. End the conversation.
Who holds the production signing keys after launch — you or us? Strong answer: you do. The client should control production keys, with contractual language confirming it. 🚩 Red flag: a vendor comfortable holding your keys indefinitely.
Walk me through the last serious bug you caught before production. How did you find it? Strong answer: a specific, technical story. It proves the review process is real. 🚩 Red flag: they can't think of one.
Scope, timeline, and honesty
What in this proposal is a proof-of-concept versus production-grade? Strong answer: a clear line drawn, with what "production-hardened" additionally requires. 🚩 Red flag: everything is described as production-ready at a demo price.
What would make you tell me a timeline isn't achievable? Strong answer: instant and specific — audit cycles, third-party dependencies, integration unknowns. 🚩 Red flag: defensiveness, or insisting nothing would.
Which parts of this project would you not build custom? Strong answer: they name proven, audited components worth reusing. It shows engineering judgment over billable hours. 🚩 Red flag: everything gets built from scratch.
Under what circumstances would you tell us blockchain is the wrong solution? Strong answer: a real, articulate answer. The best partners have talked clients out of blockchain projects. 🚩 Red flag: blockchain is always the answer.
Compliance
How do you handle compliance for tokenized assets? Strong answer: working fluency in permissioned standards like ERC-3643, KYC/AML integration, transfer restrictions, and jurisdictional considerations — described as architecture, not a checkbox. 🚩 Red flag: compliance framed as a later phase or the client's problem alone.
What regulatory assumptions is this proposal built on? Strong answer: they state them explicitly and flag where legal counsel is needed. 🚩 Red flag: no assumptions stated, no legal boundary acknowledged.
Track record
Which client engagements can I verify — references or public reviews? Strong answer: named references you can contact, or verifiable reviews on platforms like Clutch. 🚩 Red flag: a wall of impressive logos with nothing checkable behind it.
Who specifically will work on this, and what have they shipped? Strong answer: named engineers and their actual production experience. 🚩 Red flag: senior people in the pitch, juniors on the delivery.
Ownership and after launch
Who owns the IP, and what documentation do we receive? Strong answer: you own what you pay for, with clean documentation and a defined handover. 🚩 Red flag: ambiguous IP terms, or no pre-existing IP carve-out clarity.
What does support cover after launch, for how long, and at what cost? Strong answer: a defined warranty period, a monitoring and incident-response plan, and transparent ongoing pricing. 🚩 Red flag: the engagement ends at mainnet.
What happens if we want to take this in-house or switch partners in a year? Strong answer: they explain how handover works without hesitation. 🚩 Red flag: any answer that sounds like lock-in.
How to read the answers
Pay less attention to the content of the answers and more to the shape of them. Strong partners answer directly, admit limits, name specific risks, and push back when you're wrong. Weak ones get vague, get defensive, or agree with everything.
The vendor who tells you your timeline is unrealistic and your scope needs cutting is almost always the better hire than the one who says yes to everything. Enthusiastic agreement is a sales technique. Honest friction is what engineering discipline sounds like.
The bottom line
Bring this list to the final conversation and ask the questions cold. Fifteen minutes of direct questioning will tell you more than fifty pages of proposal — and the answers are cheap compared to what a wrong hire costs once real value is on-chain.
RWaltz has built blockchain and enterprise systems since 2000, with dedicated Web3 delivery since 2017 — smart contract development and audits, RWA tokenization, DeFi, and custom enterprise software. Ask us these questions.
📖 Read the full blog: https://www.rwaltz.com/blogs/questions-to-ask-before-hiring-a-blockchain-development-company
Connect with RWaltz:
LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Website: https://www.rwaltz.com
Top comments (0)