Late at night. So late you could feel the sun approaching the hemisphere where I stared at the computer screen. We had built and launched a blockchain. Blocks were rolling in one by one.

Block 1... Block 2…

I’d refresh the explorer, check logs, and run diagnostics.

I was now on-call 24/7.

It wasn’t like we just got the idea to build a blockchain. We began building on top of other blockchains. It didn’t work out. In 2015, a blockchain platform upon which early versions of our platform were being built required a mandatory update. It wasn’t the first.

It was a non-backward-compatible update that increased fees and broke the APIs being used. The projects were made economically unviable overnight. It changed the way we thought about blockchains.

We published a manifesto declaring independence from any single blockchain.

'We the asset holders hereby declare our independence from any single blockchain.' From those ashes rose a sovereign multi-chain network secured by Bitcoin itself."

Constant Iterations

In the early days, we started small, experimenting with building on top of existing blockchain platforms, like NXT platform. That platform’s non-backward compatible updates, which sometimes came with fee hikes and API breaks, rendered the apps we built economically unviable.

Next, we experimented with Bitcoin Dark, which aligned with our team’s values. Nonetheless, we hit limitations as our focus shifted from a single privacy coin to developing a broader open-source ecosystem upon which independent blockchains can launch.

We prioritized a forkable, sovereign chain. To never build critical infrastructure dependent upon an outside team and their roadmap.

This lesson and others inspired the “Blockchain Declaration of Independence) Feb 2016 on Bitcointalk, in which digital asset holders declared sovereignty from any particular blockchain.

The declaration explicitly mentioned atomic asset transfers, BTC-native trading, and blockchain-agnostic interoperability. A movement for cross-chain atomic swaps and interoperability standards followed.

It was the moment the space pivoted to multi-chain architecture. Our technical insight as a team, such as understanding atomic swaps before they became a household term, helped us in the long-term. Our first focuses were security. Once we forked Zcash-adjacent code, our GitHub commits exploded.

We began to go public with some of our identities, which helped us attract talent and credibility. With it, came increased scrutiny. We had to stay focused on the mission. A technical-first team, with clear specs, kept us on track. Meticulously-kept forums and docs prevented drift.

Releasing The Genesis Block And Fundraising

Our__genesis block__ was mined in Q4 2016. Although we were building critical infrastructure, we stuck to a modest, seven-figure funding level during the ICO with our tokenomics maintaining only 10 percent earmarked for ops.

The funds were mostly reserved for BTC notarization fees for our consensus method inspired by proof-of-work. We couldn’t overpromise. Developer team incentives, and those of the broader community, were aligned.

We stayed focused on delivering utility–at first, our consensus method for 51 percent protection via Bitcoin hashrate recycling.

This is where stepping outside of our comfort zone came in. We maintained strict community Q&A on BitcoinTalk. We shipped despite market volatility.

This disciplined us against overpromising.

Primary sources like the Bitcointalk ANN thread show intense community Q&A; we shipped despite volatility. Lesson for founders: Align incentives transparently (team allocation small/long-term).

Open-Source Blockchain Development

As our community grew, coordination amongst open-source developers proved hard. We iterated relentlessly. We made thousands of commits over a period of years . We shipped code with usability hurdles, which ultimately led us to pivot to GUIs.

We learned to ship MVPs, receive feedback on BitcoinTalk, Reddit, and Discord, and conducted stress tests. Each experience hardened our security-first focus. If we tried to do too much, we would burn out. Iterating over time on secure and useful utility compounds.

As a decentralized team, communications proved critical. We gave updates every Tuesday, posted blogs regularly, and operated exclusively on GitHub so all updates were public. Market factors were always a roller coaster ride. With GitHub, we proved we were working even during bear winters.

We took a path from pseudonymity to transparency. Choosing to be transparent was key to gaining trust. We iterated relentlessly via primary sources, forums, and GitHub. Despite being a group of cypherpunks, we learned to delegate and document relentlessly like a Silicon Valley startup.

Blockchain networks must be antifragile. We adapted to breaks and hacks, which inspired ideas for further decentralization. Whenever we shipped, we were publicly scrutinized. We prioritized security and interoperability on the path to making theory reality in open-source fashion so that our work would outlive us.

The Advantage of Technical Founding Teams

If you’re a team of developers thinking of starting your own company, you’re not alone. Successful companies are generally founded by technical founders.

Being a technical team means you can keep all product development in-house instead of outsourcing.

You also hold an advantage when creating product-market fit due to a pinpoint understanding of the technology, its capacity, and the ability to iterate quickly without needing to relay messages between engineering and businesses.

Builder to Leader Pipeline

The biggest challenge is moving from building to leading. There will be times when you need to code and times you need to lead. Leadership quality is as important as code quality.

You’ll have to evolve from being technical, and always behind the computer, to being a multiplier who builds systems, develops leaders, speaks to the media, and at conferences.

Our growth stalled if we slipped back into individual contributor mode for longer than necessary.

To avoid that, we had to divide responsibilities and develop complementary strengths. We had one developer-founder owning product vision, another focused strictly on big picture operations, while I owned deep technical architecture, and engineering culture. Specializing early allowed us to avoid making every decision by committee.

We learned to yield control and trust others to execute. You can’t stay on top of everything yourself. You must build an organization that operates without needing your constant involvement.

We were building a blockchain, which gave us a particular advantage as a technical founding team. Our first priority was to build premiere robust infrastructure.

We then focused on going to the market so as to not under-index on customer acquisition.

A Breakdown For A Technical Startup

1. Technical DNA for fast, high-quality building

2. Don’t be the bottleneck; adapt your leadership style

3. Divide roles among technical co-founders

4. Bring in non-technical skills (sales, marketing, operations) earlier than later.

5. Build systems and culture beyond the founder's involvement.

We continually reminded ourselves that we were building a company, not just a product. Think in terms of systems, delegation, and leading, and not pure coding. Never forget technical skills represent a core competitive advantage. Obsess over code quality and revenue growth.

What’s your biggest lesson building in Bitcoin and crypto? Drop it in the comments.