Transpact began as one of those hackathon ideas that sounds ambitious enough to be exciting and slightly unreasonable to build in the time available.
We wanted to make contract management more transparent. The idea was to use the NEAR blockchain for agreements and fund movement so that the people involved in a contract could see what was happening instead of relying on blind trust.
We built the first version in around 16 hours. That prototype later became my first real experience of trying to turn a project into a startup.
The path through MLH Prep
Before the incubator, I joined the MLH Prep Program. It was only three weeks long, but it changed how I worked with a team.
I learned technical things, of course. The bigger learning was how to collaborate with people from different places, divide work, explain a blocker, review someone else's contribution, and still move one shared project forward.
At that stage in my journey, I had built many things during hackathons. Prep helped me understand the habits required to build with other people after the hackathon energy disappears.
From prototype to product
Transpact was selected for the MLH Web3 Incubator, a program supported by the NEAR ecosystem. The program ran from July to September and included monthly sprints, demo days, product guidance, technical mentorship, and access to NEAR Horizon credits.
Suddenly, the questions changed.
- Who exactly has this problem?
- Why would they trust a blockchain-based solution?
- Which parts belong on-chain, and which parts do not?
- What is the smallest version someone could actually use?
- How could this product eventually sustain itself?
A hackathon asks, can you make this work? A startup asks,should this exist, for whom, and will they return? That was a completely different type of problem.
What we built
Transpact became a contract management system on NEAR Protocol. The platform used smart contracts as tamper-resistant records and a multisig flow between the contractor and the person funding the work.
The goal was simple even if the technology was not: make agreements clearer, make money movement visible, and give both sides more confidence about how funds were being used.
We used React and Tailwind CSS on the frontend, NEAR for the blockchain layer, and Rust for smart contracts. It was our first time building a complete dApp on NEAR and our first serious experience writing smart contracts in Rust.
There were many moments when the documentation became our closest teammate.
The difficult parts were not only technical
Learning Rust and understanding smart contracts was hard. Making the interface responsive was hard. But the most uncomfortable part was learning to stop treating our own assumptions as user research.
We had to talk to people, listen to how they already handled contracts, and accept that a technically interesting feature might not matter to them.
Building a product means falling in love with the problem, not with the first version of your solution.
I also learned that a team can move quickly only when ownership is visible. Everyone needs to know what they are responsible for, when they are blocked, and what the next demo must prove.
What my first startup attempt gave me
Transpact did not turn me into a perfect founder. It did something better: it removed the mystery around starting.
A startup was no longer a logo, a pitch deck, or a big announcement. It was a repeated cycle of building, showing, listening, changing, and trying again.
I learned how to take feedback without treating it as a personal rejection. I learned that a demo creates clarity faster than a long discussion. I learned that distribution and user trust deserve as much attention as code.
Most importantly, I learned that a project becomes a product only when someone outside the team finds it useful.