100 Days of Building on Solana: How I Went From Zero to Shipping On-Chain (And Survived the All-Nighters) -Hala Kabir an 11 year old girl

"After 100 days of building on Solana, the most important thing I understand now is that Solana isn’t just a faster EVM—it’s a fundamentally different mental model where accounts are databases, PDAs are business rules, and shipping to devnet is where real engineering begins."

One hundred days ago, Solana was unfamiliar territory. I stepped into this journey with assumptions from traditional Web2 software development, python syntax analyzer workflows, and standard web applications. Fast forward through 100 consecutive days of challenges, countless failed terminal commands, RPC timeouts, DNS hiccups, and a final 16-hour non-stop all-nighter—and I just shipped my capstone program to Solana Devnet.

If you are a Web2 developer, an aspiring Web3 engineer, or someone sitting on the fence about learning Solana, this is the story of my 100 days—the good, the brutal, and the moments where everything finally clicked.

1. Where I Started & What I Expected

Coming into this program, my world revolved around Python, Next.js, FastAPI, Flask, and Tailwind CSS. I was comfortable with traditional server-database paradigms: state lives in PostgreSQL or MongoDB, APIs mutate state, and authentication relies on standard JWTs or sessions.

When I started learning Solana, my Web2 brain naturally tried to map everything to familiar concepts:

• "Programs are like backend servers." (Spoiler: They aren't; programs are stateless code executors).
• "Accounts are like wallet balances." (Spoiler: Accounts are the entire database).
• "Transactions are just API calls." (Spoiler: They are explicit sets of atomic instructions with fine-grained account constraints).

In the beginning, those mental models didn't just fail—they caused bugs, failed Anchor builds, and confusing terminal errors.

2. The 100-Day Evolution: Milestones That Changed Everything

Rather than listing all 100 days line by line, here is how the journey actually broke down across the core arcs of understanding:

Arc 1: The Account Model Mental Shift
In traditional Web2, a server holds logic and state. On Solana, programs are completely stateless. State lives in Accounts, and programs merely execute logic against data passed into them. Realizing that rent, space allocation, and account ownership govern everything on Solana was the first major "aha!" moment.

Arc 2: Tokens & Minting (Token-2022)
Moving through token creation, SPL tokens, and Token Extensions (Token-2022) opened my eyes to how flexible on-chain assets can be. Configuring mint attributes, authority delegations, and zero-knowledge/cryptographic concepts shifted my focus from simple balance transfers to building custom financial primitives.

Arc 3: Anchor & Program Derived Addresses (PDAs)
Writing raw Rust for Solana programs is powerful, but discovering Anchor felt like going from plain assembly to full-stack web frameworks.

The single most important technical concept of the entire 100 days was PDAs (Program Derived Addresses):

• A PDA is an address generated without a private key using specific seeds and a program ID.
• It allows programs to sign transactions programmatically and enforce business constraints on-chain.
• The realization: A PDA isn't just an address—the address is the rule.

Arc 4: Testing & Security Constraints
Building a program isn't done when the happy path works. Writing TypeScript integration tests using mocha and chai forced me to test failure paths, input length constraints, authority checks, and re-initialization attacks. Testing how a program fails taught me more about Solana security than reading any best-practices guide.

3. The Grand Finale: Shipping the Capstone (Proof of Ship)

For Day 99, the task was clear: Design, test, and deploy a custom Anchor capstone program to Devnet, then verify it on a public explorer.

I built proof-of-ship, an Anchor program that allows any wallet to permanently record on-chain that it successfully completed and shipped its capstone.

The On-Chain Architecture
The program enforces a strict business rule: Each wallet gets exactly one permanent record on-chain. The PDA seed derivation [b"ship", builder.key()] guarantees that a wallet cannot ship twice the runtime itself rejects re-initialization.

lib.rs State & Constraint Design:

use anchor_lang::prelude::*;

declare_id!("D2Fvpwxr9QxEyd94jJFQDkAq1LiD5sySYf7KP1CUCFoRQQ");

#[program]
pub mod proof_of_ship {
    use super::*;

    pub fn ship(ctx: Context<Ship>, project_name: String, message: String) -> Result<()> {
        require!(project_name.len() <= 64, CapstoneError::NameTooLong);
        require!(message.len() <= 256, CapstoneError::MessageTooLong);

        let record = &mut ctx.accounts.ship_record;
        record.builder = ctx.accounts.builder.key();
        record.project_name = project_name;
        record.message = message;
        record.shipped_at = Clock::get()?.unix_timestamp;
        record.bump = ctx.bumps.ship_record;

        Ok(())
    }
}

#[derive(Accounts)]
pub struct Ship<'info> {
    #[account(
        init,
        payer = builder,
        space = 8 + ShipRecord::INIT_SPACE,
        seeds = [b"ship", builder.key().as_ref()],
        bump
    )]
    pub ship_record: Account<'info, ShipRecord>,
    #[account(mut)]
    pub builder: Signer<'info>,
    pub system_program: Program<'info, System>,
}

#[account]
#[derive(InitSpace)]
pub struct ShipRecord {
    pub builder: Pubkey,
    #[max_len(64)]
    pub project_name: String,
    #[max_len(256)]
    pub message: String,
    pub shipped_at: i64,
    pub bump: u8,
}

#[error_code]
pub enum CapstoneError {
    #[msg("Project name must be 64 characters or fewer")]
    NameTooLong,
    #[msg("Message must be 256 characters or fewer")]
    MessageTooLong,
}

4. The Real Engineering Moment: Surviving the All-Nighter

Tutorials always make shipping look like a clean anchor deploy command. Real software engineering is much grittier.

On the final stretch leading into Day 99/100, I worked straight through from 12:00 AM to nearly 4:00 PM without a single minute of sleep. When it came time to deploy to Devnet, everything that could go wrong did:

1.** Keypair Errors:** No default signer was set on my Windows path.

1. Pathing & Anchor Issues: unrecognized signer source errors required running anchor keys sync and deploying directly via the Solana CLI.

2. DNS Outages: Windows throws os error 11001 (dns error: No such host is known) when trying to hit api.devnet.solana.com.

3. Explorer Glitches: The official Solana Explorer UI suffered an RPC outage right as I was searching for my deployed program ID!

Pushing Through to Success
By flushing Windows DNS (ipconfig /flushdns), switching RPC endpoints, and validating the deployment directly via Solscan Devnet, I officially verified my live executable account:

1.Deployed Program ID: D2Fvpwxr9QxEyd94jJFQDkAq1LiD5sySYf7KP1CUCFoRQQ

2.Cluster: Solana Devnet

3.Live On-Chain Verification: Solscan Devnet Account Page

When that green Program Id output printed in PowerShell after 16 continuous hours of troubleshooting, the feeling was unmatched.

5. What I Would Tell Another Developer Starting Day 1

If you are just beginning your 100 Days of Solana, here is my practical advice:

Embrace the Errors: Solana CLI error messages look intimidating at first. Read them carefully—90% of the time, it's either an RPC endpoint timeout, a missing keypair file, or a space constraint mismatch.

Master PDAs Early: Don't just copy-paste seed macros. Spend an afternoon understanding why Pubkey::find_program_address works and how seeds prevent unauthorized state overwrites.

Always Have Backup RPCs: Public devnet endpoints (api.devnet.solana.com) will rate-limit or fail DNS lookups when you need them most. Always keep a free custom RPC endpoint (from Helius, QuickNode, or Ankr) in your .env or deploy flags.

Consistency > Perfection: You don't need to understand the entire architecture on Day 1. Just keep building, keep reading logs, and keep pushing code daily.

6. What Comes Next

Completing 100 Days of Solana isn't the finish line—it's the foundation.

With this on-chain capability unlocked, I am taking these learnings directly into my ongoing full-stack and decentralized projects. Whether it's integrating cryptographic zero-knowledge proofs, building web dashboards, or deploying production-ready Anchor smart contracts, the mental model I built during these 100 days will back every architecture decision I make going forward.

To everyone who organized, supported, and built alongside this cohort: Thank you.