GitMyABI

GitMyABI is a smart contract developer platform from AxLabs. It helps teams turn Hardhat and Foundry projects into versioned contract artifacts they can actually use in applications.

The primary path is GitHub: connect a repository, configure the framework and build settings, and trigger builds on commits or manually. Each successful build produces ABI JSON served from a CDN and generated TypeScript bindings published as an npm package. The dashboard shows the install command, CDN URLs, and build history tied to specific commits.

There is also an Etherscan import path for verified on-chain contracts. Search by address, start ingestion, and the platform creates a project with the same artifact outputs without requiring a GitHub repo upfront.

I was the only frontend engineer on the product and owned the UI direction as well as the implementation. There was no handed-off design track for most of the application, so I shaped the dashboard, onboarding flows, build and ABI views, public team and project pages, and shared application shell directly from product requirements.

The backend API, build workers, and publishing infrastructure are separate services. My work was turning those outputs into a browser-based product that developers could understand and trust.

The problem

Smart contract integration work repeats the same painful steps. ABIs get copied manually. Typed clients drift after contract changes. Artifacts are hard to trace back to a specific commit or build. When something fails, the failure often shows up minutes later in a log stream the developer was not watching.

GitMyABI automates the build and publish step, but that does not remove complexity from the user experience. Builds queue, run, complete, or fail asynchronously. Etherscan imports follow their own job lifecycle. Logs stream in real time while status updates arrive on a different cadence. Tier limits gate some outputs.

Frontend teams and contract developers do not need another opaque pipeline. They need to see what source is connected, what branch and framework is being built, whether a job is queued or running, where the ABI files landed, what CDN URL to copy, what npm package to install, and which build produced the artifact. The product only works if the UI answers those questions clearly.

What I worked on

Project setup. Multi-step onboarding for GitHub-backed projects: repo and branch selection, Hardhat or Foundry configuration, build commands, environment variables, and artifact path selection through a file explorer. Separate import flow for Etherscan contracts with team and project assignment.

Build monitoring. Project overview, builds list with status filtering, and build detail pages with commit metadata, delivery snapshots, and live log streaming for build and codegen output. Explicit states for queued, running, completed, and failed builds instead of empty pages or generic spinners.

ABI viewer. Searchable ABI file list with CDN URL copy, origin URL visibility, and content gated on build completion. Clear messaging when a build is still running or has failed.

Type bindings surface. Timeline of builds with generated npm package install commands and links to per-build type binding output. Designed so a developer can go from build to installable client in one view.

Contract search and Etherscan import. Homepage search by project name or contract address. Database results first, Etherscan ingestion preview when no match exists. Dedicated ingestion progress UI with step indicators and status handling through pending, processing, completed, and failed states.

Public artifact pages. Team and project pages with release timelines, ABI file copy, chain deployment metadata, and npm install snippets. Explore directory for discovering published projects across teams.

Shared product patterns. Consistent loading, empty, error, and success states across dashboard surfaces. Typed API boundaries, reusable data wrappers, and error recovery for transient failures. Team settings and Stripe billing UI as secondary surfaces within the same application shell.

Technical approach

App structure. Next.js App Router with thin routes and feature components. Project and build context providers share fetched state across nested dashboard pages without prop drilling.

Server state. TanStack Query hooks organized by domain. Build lists poll on an interval. ABI queries enable only after build completion. Responses validated with Zod at the fetch boundary so malformed API data fails early instead of breaking the UI.

Real-time feedback. Socket.IO streams build and codegen logs with connection status visible in the log viewer. Status polling and log streaming run on separate channels, so the UI treats each explicitly rather than assuming they stay in sync.

Async state modeling. Build and ingestion flows each have defined lifecycle states. Components render different surfaces for queued, running, completed, and failed conditions with actionable copy where recovery is possible.

UI foundation. Atlas UI primitives extended with GitMyABI-specific components for build status, chain metadata, and team navigation. Tailwind CSS surface tokens for consistent elevation across light and dark modes.

Error handling. Sentry at the app root, route-level error boundaries, and component-level wrappers with retry for transient failures. API errors normalized to structured problem details with user-facing messages.

Billing. Stripe checkout and billing portal integrated as UI flows. Plan limits surfaced through paywall components so users see restrictions before hitting backend enforcement.

Result

GitMyABI turned backend-heavy build and publish infrastructure into a navigable developer dashboard. Async workflows that could feel opaque now have explicit status, logs, and artifact delivery surfaces.

Developers get one place to find ABI files, CDN links, npm packages, and build history tied to commits. The public project pages extend that same clarity to published artifacts outside the authenticated app.

The frontend work created trust in a Web3 developer tool by treating state handling, error recovery, and typed data boundaries as product requirements, not polish added at the end.

What I would improve next

Build comparison. Side-by-side view of ABI and binding changes between two builds so teams can see what shifted after a contract update.

Failed build recovery. More guided troubleshooting from failed build states, linking log errors to common configuration fixes and docs.

Public project depth. Richer public pages with clearer release history, framework context, and artifact discovery for teams browsing without an account.

Docs-to-dashboard continuity. Tighter connection between in-app docs, CLI setup, and the dashboard flows they describe so onboarding stays in one mental model.