Security-first
MVP Development for Web3 Startups
My research background is cybersecurity and I have written on smart contract security, which shapes how I scope a web3 MVP: the contract surface stays as small as it possibly can, because every line of it is adversarial code holding real money.
Most web3 MVPs I see put too much on-chain. It is slower to build, far more expensive to get wrong, and irreversible in a way normal software is not. The scoping week is largely about deciding what genuinely needs to be on-chain and moving everything else off it.
How the build runs
What is different about scoping a web3 MVP
The on-chain surface gets minimised before anything is written
Every function you deploy is code an attacker can call with money at stake, and code you cannot patch the way you patch a server. I go through the feature list and move everything that does not strictly require consensus off-chain. Smaller contracts are cheaper to build, cheaper to audit, and dramatically less likely to lose someone's funds.
Use audited standards rather than writing your own
Token standards, access control, upgradeability patterns. OpenZeppelin's implementations have been reviewed by more eyes than any MVP budget can buy. Writing your own version of a solved problem is how MVPs end up with novel bugs in well-understood territory.
The build is structured for an audit you have not booked yet
A third-party audit is expensive and priced partly on how legible your code is. Clean separation, thorough natspec, and a full test suite meaningfully reduce what an auditor charges and how much they find. I build assuming the audit is coming, because for anything holding real value it is.
Key handling is decided early and never improvised
Whether users hold their own keys, whether you use a custodial provider, and how deploy keys are secured. These decisions shape the entire UX and the entire risk profile. Improvising them mid-build is how teams end up with a deploy key in an environment variable on someone's laptop.
Most of the screen count is the off-chain application
The contracts are usually a small fraction of the work and a large fraction of the risk. The wallet connection, the transaction states, the pending and failed and reverted cases, the indexer reading chain state: that is where the screens are. I price them plainly and quote the contract work separately, because they are genuinely different kinds of work.
Scope
What a v1 looks like here, specifically
Screen counts are a starting point, not a quote. The real number comes out of the scoping week, and it is almost always lower than the brief that walked in.
8 to 14 screens
Typical v1 for a web3 product, plus a separately quoted contract scope
Goes in v1
- Wallet connection with honest pending, failed, and reverted states
- The minimum viable contract surface, built on audited standards
- A full test suite covering the adversarial cases, not just the happy path
- An indexer so the app reads chain state without hammering a node
- Testnet deployment and a documented deploy process
Deliberately deferred
- Custom token standards where an audited one exists
- Multi-chain deployment before one chain has users
- On-chain governance until there is something to govern
- Upgradeability proxies unless the risk genuinely justifies the complexity
What you're actually buying
Scoping, the build, and launch
Week 0
Scoping: every screen counted and priced
We go through everything you think the MVP needs, screen by screen, and cut it down to what actually has to exist to test the thing you're testing. Every remaining screen gets counted and priced at $80, across whichever platform it needs — mobile, web, desktop, or Linux. You leave with a scope doc and a total, not an estimate that moves once we start.
The build
Design and development, with you seeing it every week
My Panicle Tech design and engineering team builds it, screen by screen; I own the architecture, the code review, and the calls that are expensive to get wrong. You get a working build to look at every week, not a status update. If a screen turns out to need more than was scoped once it's half-built, that gets priced honestly before it's fully built, never absorbed silently.
Launch
Handover, and two weeks of me still answering the phone
Deployed, monitored, and documented well enough that the next engineer who touches it isn't guessing. Two weeks of post-launch support are included, because the bugs that matter are the ones your first real users find, not the ones QA finds.
Why me, for this market specifically
Experience, not a capabilities deck
Plenty of teams can build screens. Fewer have shipped for Web3 specifically, been wrong about it, and had to fix it with their own name on the commit. Here's what I'm bringing.
- M.Tech in Cybersecurity, NIT Kurukshetra, with 30+ academic citations
- Published on smart contract and application security
- Six ventures built 0 to 1 across three continents
- Security-first by training, which in web3 is the whole job
Pricing
from $80 a screen. Counted up front.
Design and build, screen by screen, across mobile, web, desktop, and Linux. My Panicle Tech team designs and builds it; I own the architecture and the technical decisions as advisor on the project. Added screens are priced at the same rate, never renegotiated after the fact.
MVP Design & Development
from $80
per screen
- Scoping week: every screen counted and priced up front
- UI/UX design and full-stack development, screen by screen
- Built by my Panicle Tech design and engineering team
- I own the architecture, code review, and technical direction
- Mobile, web, desktop, and Linux apps, whichever the product needs
- Deployment, monitoring, and handover documentation
- Two weeks of post-launch support
- Added screens priced at the same per-screen rate, never renegotiated after the fact
- Option to continue on a fractional retainer
Questions
Web3, specifically
Are the smart contracts priced per screen?
No. Screens are the application interface. Contract work is quoted separately as a fixed scope, because it is a different discipline with a different risk profile and it would be dishonest to average it into a screen rate. You get both numbers before anything starts.
Do you provide the security audit?
No, and you should be wary of anyone who offers to audit their own code. I build so an independent audit goes smoothly and costs less, and I can point you at firms. The independence is the entire value of an audit.
Which chain should we build on?
That is a scoping-call conversation and it depends on where your users are, what fees they will tolerate, and what tooling exists. I have opinions but they are downstream of your answers. What I will push for is choosing one and shipping on it rather than building for three.
Can you do the frontend if we already have contracts?
Yes, that is a common shape. I will read the contracts during scoping first, because their design constrains what the interface can honestly show, particularly around transaction states and failure handling.
More general questions about pricing, timeline, and what's included are answered on the main MVP development page.
Earned, Not Claimed
What the founders and teams I build with say
I had the pleasure of working with Kunal while building out my MVP and I have to say that it was pleasure to both interact and work with him and his team. As a first time founder, I had a lot of self doubt and internal ruptures, however Kunal's calm, never-say-die and never-panic attitude often helped bring me back to center. I can't vouch for him enough.
Anand Tahiliani
Founder, Debaser Technologies
I had the pleasure of working closely with Kunal during my time as a Product Manager at DhunGuru. As our CTO, Kunal and his team at Panicle Tech worked closely with me across the entire product journey, from building and launching our mobile apps to developing and maintaining our web platforms. His technical expertise, ownership, and willingness to collaborate made a real difference, and I genuinely enjoyed working with him throughout the journey.
Anirudh Joshi
Product Manager, DhunGuru
Kunal helped us architect Mosler's core platform, connecting smart lock hardware, our cloud dashboard, and PMS integrations into one reliable system. The foundation he helped design in those early days still scales with us today.
Pranav Kapoor
Co-Founder, Mosler
If you need more than a build
Already have a product, not just an MVP?
High-stakes code
Fractional CTO for Web3 and Crypto Startups
For Web3 teams that already have a product and need ongoing technical leadership, not a single per-screen build.
See the Fractional CTO page for Web3 →
Building a Web3 product? Let's scope it.
Thirty minutes. Tell me what you're building, and I'll give you a straight read on the screen count and the total before anything gets built.
Book a 30-min callSend me a message