Web3 experience
Our blockchain experience came both from individual commissions and from an ecosystem we ran for years together with its owners and their team. This page is about what we understand in this field and how we know how to develop it.
It started with curiosity. Bitcoin appeared and we wanted to know what it actually was. After that, through individual tasks, we gradually went deeper into blockchain and smart contracts: the market was not formed yet and the work was episodic, but we never passed up a chance to figure things out. When it became clear that this was going beyond a trend and turning into a field of its own, there was a period when we concentrated on it seriously.
At some point the accumulated experience was enough for more than a single smart contract or adding crypto payment to one particular game or service. It was enough to join a living ecosystem and to gradually update and rebuild its services together with the owners and their established team. The Ubix.Network chain was running while the services around it lived separately: different technologies, different design, different approaches to updating. We brought them to common standards. In some places a new interface was enough, some parts were rebuilt entirely, some were built from scratch. That is how the wallet, the exchange, the staking platform, the network explorer and the ecosystem analytics came together, while two blockchain document services grew separately: Silent Notary and SignItNow.
About the market it is worth speaking plainly. Everyone touches crypto these days: a developer who has more or less learned the tools already issues their own token, and some of those stories end badly for the people who put money in. An outsider ends up holding two beliefs at once. First, that money is made here, sometimes a great deal of it. Second, that anyone at all is climbing into it. Telling apart a problem in the technology itself from simply having hired incompetent people is hard for a layperson, and the price of that mistake is always measured in money.
Hence the main difference from ordinary development. A crypto product is not a banking app where support will return a mistaken transfer to the account. Here, the moment a person signs an operation with their key, the funds are gone, and the chance of seeing them again is close to zero. They will not always even learn whom they made richer with that move. So in these products experience in design and interface work turned out to matter no less than the code.
The user meanwhile passes through two states, and both are dangerous. First they doubt: did I press the right thing, did I send it to the right place, will I lose everything. An experienced trader moves freely around an exchange terminal, but they too once started exactly like that. Then comes the moment when a person feels they have understood it all, and mistakes happen precisely there: sent to the wrong place, behaved unexpectedly, signed without looking. The interface has to carry a person through both states, and irreversible actions are designed so that making a mistake is hard.
This changes the engineering as well. The system cannot be stopped: sometimes twenty minutes of downtime costs more than all the developer work on a release that went out badly. Trust in this field is gathered grain by grain and lost in a single incident, so the requirements for code quality, for testing, for infrastructure and for the release procedure are higher than usual.
And still the technical part is the tip of the iceberg. Choosing a language, assembling infrastructure and distributing load are things many can do. The underwater part, the one a business liner breaks against, lies outside engineering. You built a wallet, a thousand people used it, development broke even. What then? Where does the money come from, how does it grow, who comes back tomorrow and why. Not every team can answer that, and this is exactly where accumulated experience turns out to be decisive. We did the same kind of review for the game project Battle of the Bees.
If a product needs building from scratch, that is Web3 development: smart contracts, wallets, exchanges. Such products are built by frontend and backend, an idea can be tested before development through prototyping, and making sense of something that already runs is the job of an audit and business consulting.
What the service covers
Any combination of the items below can be taken on its own.
What is happening around, what people actually use, where the product loses them and what it will earn from after launch. The review comes before the screens rather than after.
When there are several products and they look and behave differently, we bring them to a common interface, common technologies and a common update procedure.
We step into the existing code and infrastructure, work out how it is built, close the bottlenecks and keep developing it together with your team.
Confirmations, checks, readable transaction states and protection against acting blind. A separate piece of work that in crypto costs more than mistakes in the code.
Backward compatibility, a rollback plan, switching over in parts. On the exchange this was a hard requirement, and we have the procedure worked out.
Tokenomics, pricing, free quotas, reasons to come back. We work it out before development and hand it over as a document, the decision is yours.
How we work
What has been built, what it rests on, where the risks are. We look at the code, at the product and at how people use it.
What to fix now, what to develop, what does not need rewriting at all. An estimate by stage.
Two-week iterations with a demo, updates without stopping the service.
Documentation, handover to your team, further development by agreement.
Stack and tools
Cases for this service
Frequently asked questions
By a whole ecosystem and the services inside it: a wallet, an exchange, staking, a network explorer, analytics, two blockchain document services and a game project. In the case studies this is not a set of interface screenshots but the story of each service: where it started, which decisions were taken and why, and what worked.
Yes, that is the main scenario here. First we review the state of the code and the infrastructure, then we say plainly what is cheaper to improve and what to rewrite.
Almost always, and on the exchange that is exactly what we did. It costs more than an ordinary release, and we discuss it before the work starts.
We review the market, work through the options and hand over a document with proposals. The decision stays with you.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. During the project the team works either on our infrastructure or on yours: the choice depends on the complexity of the project and on whether you already have infrastructure in place. Every approved stage is transferred to your servers and your repository, so the work accumulates on your side rather than ours. Once the project is closed, all code, materials and documentation are handed over to you together with the rights to them.
Yes, under a separate agreement: on-call duty, monitoring, updates and development.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.