Forem: Akshith Anand

Beyond Trading: Building a 'Programmable Treasury' for B2B Payments

Akshith Anand — Thu, 15 Jan 2026 17:07:11 +0000

The Problem with Traditional B2B Payments

If you've ever run a business or worked as a freelancer, you know the pain of cross-border payments.

High Costs: Fees and currency markups often exceed 6%.
Slow Speed: Settlement takes 2-5 days due to intermediary banks.
Zero Transparency: "Where is the money?" is a question no one can answer until it arrives.

We are building apps in 2026, but moving money like it's 1996.

The Solution: A Programmable Treasury

A programmable treasury transforms payments from a manual task into an automated function of your code. By leveraging stablecoins like USDC (which are pegged 1:1 to the dollar), we can settle invoices instantly based on logic we define.

Automated Execution: If Condition A is met, pay Person B.
Real-time Liquidity: No "banking hours." 24/7 settlement.
Stability: Using stablecoins avoids crypto volatility while keeping the speed.

The Tech Stack

To build this, we need a hybrid Web2/Web3 stack:

Frontend (Next.js): For the dashboard where you configure payment rules. It handles the wallet connection (via RainbowKit or similar) and visualizes transaction status.
Backend (Node.js): The workhorse. It listens for real-world events (webhooks) and acts as an "Oracle" to tell the blockchain what happened.
Blockchain (Aptos or Solana): We need high throughput and low fees. Paying $5 in gas for a $50 invoice doesn't work. Solana and Aptos allow for sub-cent transaction fees and sub-second finality.

The Workflow: From GitHub PR to Bank Account

Here is the event-driven architecture we are building:

The Trigger: A developer merges a Pull Request on GitHub.
The Listener: GitHub sends a webhook to our Node.js server.
The Verification: The server validates the PR_ID and matches it to a registered contractor address.
The Execution: The server calls the Smart Contract.
The Settlement: The Smart Contract checks its balance and instantly transfers USDC to the contractor.

The Code Logic

Here is pseudocode for how the Smart Contract handles the logic. Notice we are separating the "Trigger" (Oracle) from the "Funds" (Contract).

Solidity

contract PaymentProcessor {
  mapping(string => address) public prToContributor;
  USDC_Token public usdc;

  constructor(address _usdcAddress) {
    usdc = USDC_Token(_usdcAddress);
  }

  // Admin registers which PR belongs to which user
  function registerContributorPR(string memory _prId, address _contributor) public {
    prToContributor[_prId] = _contributor;
  }

  // The "Oracle" (our Node backend) calls this
  function executePaymentOnPRMerge(string memory _prId, uint256 _amount) public {
    // Security Check: Only authorized oracle can call this
    // require(msg.sender == oracleAddress, "Not authorized");

    address contributor = prToContributor[_prId];
    require(contributor != address(0), "Contributor not registered");

    // Instant Transfer
    usdc.transfer(contributor, _amount);

    emit PaymentExecuted(_prId, contributor, _amount);
  }

  event PaymentExecuted(string indexed prId, address indexed recipient, uint256 amount);
}

Why This Matters

This isn't just about "using crypto." It's about removing friction. By treating money as a programmable primitive, we can build:

Gig-Economy Platforms that pay instantly upon delivery.
Supply Chains that settle funds the second a GPS tracker enters a warehouse.
Streaming Payments for content creators.

The future of fintech isn't banks; it's code.

Account Abstraction Explained

Akshith Anand — Thu, 08 Jan 2026 01:24:43 +0000

A Glimpse into the Future of Web3

This article explores how Account Abstraction (AA), particularly through standards like ERC-4337, is revolutionizing Web3 interactions. By eliminating complexities such as cumbersome seed phrases and native token gas fees, AA paves the way for a more intuitive and accessible crypto experience, crucial for mass adoption.

Account Abstraction: The Game Changer

Account Abstraction (AA) fundamentally redefines traditional Externally Owned Accounts (EOAs). By transforming them into programmable smart contract accounts, AA unlocks Web2-like user experiences within the Web3 ecosystem. This crucial shift makes crypto far more intuitive and accessible.

Key Features & Benefits

1. Simplified Onboarding & Seed Phrase Elimination

Smart Contract Accounts: Native smart accounts allow for flexible authentication and recovery from day one.
Decoupled Keys: Signing keys are separated from the account, enabling easy rotation or replacement without asset loss.
Social Logins & Passkeys: Use existing social accounts (Google, Apple) with secure biometrics (Face ID/Touch ID) for login.
Abstracted Seed Phrases: End-users never see or store seed phrases; complex key management is handled invisibly, mirroring Web2.
Seamless dApp Onboarding: Developers can offer familiar sign-up flows, making wallet creation almost invisible.

2. Enhanced Security & Recovery

Social Recovery: Designate trusted "guardians" (friends, devices) to collaboratively regain access, acting as a multi-sig recovery.
Programmable Security: Implement custom rules like daily spending limits, MFA for large transactions, or dApp whitelisting.
Biometric Authentication: Leverage WebAuthn and passkeys for hardware-backed, convenient transaction signing via Face ID or Touch ID.

3. Flexible & "Gasless" Transactions

Paymasters: These powerful contracts enable gas abstraction, removing the native token requirement.
Pay Gas in Any ERC-20: Users can pay transaction fees using any supported ERC-20 token, not just the native chain token.
Truly "Gasless": dApps or protocols can sponsor transaction fees entirely, making user interactions feel indistinguishable from Web2.

ERC-4337 Architecture: The Engine Room

ERC-4337 implements Account Abstraction without modifying Ethereum's core protocol, using a clever, modular design.

UserOperation (UserOp)

A pseudo-transaction object encapsulating a user's intent, acting as the starting point for any action.

Bundlers

Off-chain network participants who collect UserOps, bundle them, and submit them as a single transaction to the blockchain.

Entry Point

A universally deployed smart contract that verifies UserOps, handles economic rules, and executes actions on smart accounts.

Paymasters

Optional smart contracts that enable gas abstraction, allowing dApps to sponsor fees or users to pay with ERC-20 tokens.

The Road Ahead for Web3

Account Abstraction, powered by ERC-4337, is more than just a technical upgrade; it's a paradigm shift towards an inclusive and accessible Web3. By abstracting away complex concepts like private keys, seed phrases, and native gas fees with familiar Web2 experiences such as social logins, biometrics, and flexible recovery, AA is bridging the gap for mainstream adoption. This innovation empowers developers to build truly user-friendly dApps, heralding an end to frustrating crypto onboarding and the dawn of magical, frictionless digital experiences.

Docker is Overkill: Setting Up Lightweight CI/CD for Solo Devs

Akshith Anand — Sun, 04 Jan 2026 10:38:24 +0000

Docker is Overkill: Setting Up Lightweight CI/CD for Solo Devs

As solo developers, we're often juggling coding, design, testing, and deployment – all while trying to stay sane. The promise of Continuous Integration/Continuous Deployment (CI/CD) sounds great, but when you hear terms like "Kubernetes," "Docker Compose," or "orchestration," it's easy to feel overwhelmed. Many of us just want our code to go live without a massive infrastructure headache.

Good news: you don't need a heavy Docker setup or complex container strategies to reap the benefits of CI/CD. This post will show you how to build a lean, efficient CI/CD pipeline using GitHub Actions and popular Platform as a Service (PaaS) providers like Vercel, Railway, or Render, allowing you to deploy automatically on every git push. Forget the containerization overhead; let's streamline your workflow.

Why CI/CD Matters for Solo Devs (Without the Docker Headache)

Even if you're a team of one, CI/CD can be a game-changer. It's about automating repetitive, error-prone tasks so you can focus on building features.

Here's why you should care:

Faster Feedback Loops: Catch bugs immediately. Automated tests run on every code change, preventing issues from snowballing.
Automation & Peace of Mind: No more manual build steps or remembering deployment commands. A git push takes care of everything. This frees up significant mental load.
Consistent Deployments: Eliminate "works on my machine" issues. Your deployments become reliable and repeatable.

The beauty of the solutions we'll explore is their inherent simplicity. They abstract away server management and, crucially, much of the Docker complexity. While Docker is a powerful tool, for many solo projects, its overhead is indeed overkill.

The Core: GitHub Actions – Your CI Orchestrator

At the heart of our lightweight CI/CD setup is GitHub Actions. It's GitHub's integrated CI/CD tool, and it's perfect for solo developers because:

Native GitHub Integration: It lives right where your code is. No need for external services if you're already on GitHub.
YAML-Based Workflows: Define your entire pipeline in simple YAML files (.github/workflows/your-workflow.yml) stored in your repository. This means your CI/CD configuration is version-controlled alongside your code.
Event-Driven: Workflows trigger on events like a push to a branch, a pull request, or even scheduled cron jobs.
Docker-Free Runners: GitHub Actions jobs run on virtual machines (e.g., ubuntu-latest). While you can run Docker commands within these runners, the core CI steps like checking out code, installing dependencies, and running tests execute directly on the VM, providing a Docker-free CI experience for your application's build process.

A typical GitHub Actions workflow looks like this:

on: Defines when the workflow runs (e.g., push to main).
jobs: A set of tasks to be executed (e.g., build, test, deploy).
steps: Individual commands within a job (e.g., actions/checkout@v4 to get code, npm install, npm test, vercel deploy).

PaaS Power-Ups: Your Docker-Free Deployment Targets

Once GitHub Actions handles your CI (testing, linting, building), the next step is Continuous Deployment (CD). This is where PaaS providers shine, offering automatic, managed deployments without you needing to worry about servers or container runtimes.

Let's look at three popular options: Vercel, Railway, and Render.

1. Vercel with GitHub Actions for Frontend Brilliance

Vercel's platform automatically detects your project's framework and handles the build process. You can use the Vercel CLI within your GitHub Action to interact with your Vercel project or leverage dedicated community actions.
Conceptual GitHub Actions Workflow (.github/workflows/deploy-vercel.yml):

name: Deploy to Vercel

on:
  push:
    branches:
      - main # Trigger on pushes to the main branch
  pull_request:
    branches:
      - main # Trigger for pull requests for preview deployments

jobs:
  deploy:
    runs-on: ubuntu-latest # GitHub Actions runner VM
    steps:
      - uses: actions/checkout@v4 # Checkout your repository code
      - name: Install Vercel CLI
        run: npm install --global vercel@latest # Install Vercel CLI
      - name: Pull Vercel Environment Information
        # Pulls Vercel project details. Determines 'production' or 'preview' based on branch.
        run: vercel pull --yes --environment=${{ github.ref == 'refs/heads/main' && 'production' || 'preview' }} --token=${{ secrets.VERCEL_TOKEN }}
      - name: Build Project Artifacts
        # Builds your project. Vercel's build process often produces a .vercel/output folder.
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy to Vercel
        # Deploys the prebuilt artifacts. --prod for main branch, otherwise preview.
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
        env:
          VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
          VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

This workflow automatically creates preview deployments for PRs and production deployments on main branch merges, giving you instant feedback and a live URL without touching a server.

2. Railway with GitHub Actions for Full-Stack Simplicity

Railway typically auto-detects your project's language/framework or Dockerfile (if present, but not mandatory for simple setups) using Nixpacks. You can trigger deployments via GitHub Actions using the Railway CLI or community actions.
Conceptual GitHub Actions Workflow (.github/workflows/deploy-railway.yml):

name: Deploy to Railway

on:
  push:
    branches:
      - main # Trigger on pushes to the main branch

jobs:
  deploy:
    runs-on: ubuntu-latest # GitHub Actions runner VM
    steps:
      - uses: actions/checkout@v4 # Checkout your repository code
      - name: Deploy to Railway
        # Using a community action for simplicity. Alternatively, install Railway CLI and run `railway deploy`.
        uses: CommandPost/railway-deploy@v2
        with:
          RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }}
          # RAILWAY_SERVICE_ID: ${{ secrets.RAILWAY_SERVICE_ID }} # Uncomment if targeting a specific service

Railway's "zero-config" approach handles the build and deployment on its end, often using tools like Nixpacks to containerize your app on the fly, eliminating the need for you to manage Dockerfiles yourself.

3. Render with GitHub Actions for Scalable Simplicity

Render offers a managed cloud platform that simplifies the deployment of web services, databases, and more. It provides similar benefits to Vercel and Railway, with robust scaling and a clear path from prototype to production.

This method is incredibly simple as it just triggers a pre-configured deployment on Render.

name: Deploy to Render via Deploy Hook

on:
  push:
    branches:
      - main # Trigger on pushes to the main branch

jobs:
  deploy:
    runs-on: ubuntu-latest # GitHub Actions runner VM
    steps:
      - uses: actions/checkout@v4 # Checkout your repository code
      - name: Trigger Render Deploy Hook
        # A simple curl command triggers a deployment on Render.
        run: curl ${{ secrets.RENDER_DEPLOY_HOOK_URL }}
        env:
          RENDER_DEPLOY_HOOK_URL: ${{ secrets.RENDER_DEPLOY_HOOK_URL }}

Conceptual GitHub Actions Workflow (using "Deploy to Render" Action - .github/workflows/deploy-render-action.yml):

For more fine-grained control or options like cache clearing, a dedicated action might be preferred.

name: Deploy to Render using Action

on:
  push:
    branches:
      - main # Trigger on pushes to the main branch

jobs:
  deploy:
    runs-on: ubuntu-latest # GitHub Actions runner VM
    steps:
      - uses: actions/checkout@v4 # Checkout your repository code
      - name: Deploy to Render
        # Uses a community action for deploying to Render.
        uses: johnbeynon/render-deploy-action@v0.0.8 # Check for newer versions
        with:
          service-id: ${{ secrets.RENDER_SERVICE_ID }}
          api-key: ${{ secrets.RENDER_API_KEY }}
          # clear-cache: true # Optional: to clear Render's build cache

Render handles the building, deploying, and even zero-downtime updates on its infrastructure, so you don't have to concern yourself with Docker setups on your server.

Key Considerations for All PaaS Deployments

No matter which PaaS you choose, keep these best practices in mind:

Secrets Management: ALWAYS use GitHub Secrets to store sensitive data like API keys and tokens. Never hardcode them in your workflow files.
Branch Protection: Configure branch protection rules on GitHub to prevent direct pushes to your main or deployment branches. This forces changes through pull requests, where your CI/CD pipeline can run tests before merging.
Environments (GitHub): Leverage GitHub Environments to manage different deployment targets (e.g., production, staging). This allows you to apply environment-specific secrets and protection rules (like manual approval) for critical deployments.
Start Simple: Don't try to automate everything at once. Begin with a basic build and deploy workflow, then gradually add tests, linting, and other checks as your project evolves.
Monitor: Regularly check the "Actions" tab in your GitHub repository to ensure workflows are running successfully and debug any failures promptly

Beyond PaaS: Docker-Free SSH Deployment

If you prefer deploying to your own Virtual Private Server (VPS) without Docker, GitHub Actions can still be your best friend. This involves using an appleboy/ssh-action or similar to connect to your server via SSH and execute commands.

Conceptual Workflow for SSH Deployment:

name: Deploy Node.js API via SSH

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Deploy to server via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }} # Use an SSH key securely stored in GitHub Secrets
          script: |
            cd /path/to/your/app # Navigate to your application directory
            git pull origin main # Pull the latest code
            npm install --production # Install production dependencies
            pm2 restart your-app-name # Restart your Node.js app with PM2 (or systemd, etc.)

This approach is lightweight because your build steps happen on the GitHub Actions runner, and only the necessary commands are sent to your production server, bypassing Docker entirely.

Conclusion

For solo developers, implementing CI/CD doesn't have to mean diving into the complexities of Docker and Kubernetes. By embracing the power of GitHub Actions paired with intuitive PaaS providers like Vercel, Railway, or Render (or even a simple SSH deployment), you can build robust, automated pipelines that significantly boost your productivity and confidence.

This Docker-free approach allows you to:

Ship faster with automated deployments.
Reduce errors through consistent, automated processes.
Focus on coding by offloading infrastructure concerns.

So, ditch the Docker overhead if it's not serving your solo development needs. Start with a simple GitHub Actions workflow, connect it to your favorite PaaS, and experience the joy of truly continuous delivery.

What's your preferred lightweight CI/CD setup as a solo dev? Share your thoughts and workflows in the comments below!