From ArkVerse to CoComply: My 8-Month Evolution
At ThirdStartup, nobody held your hand. A client needed a landing page, you built it from the ground up. A product needed a dashboard, you owned every screen. Requirements to deployment, every feature was your responsibility, and when something broke in production, that was your problem to fix.
At ThirdStartup, nobody held your hand. A client needed a landing page, you built it from the ground up. A product needed a dashboard, you owned every screen. Requirements to deployment, every feature was your responsibility, and when something broke in production, that was your problem to fix.
I joined as a Web Development Intern after a product development stint at REVA NEST. The agency model was different from anything I'd done before. Multiple clients, parallel codebases, real deadlines, real users depending on what you shipped. Not "build a feature and hand it off" but "build it, ship it, fix it when it breaks, and iterate when users find what you missed."
Early projects were landing pages. Property Pro Legal needed one for their legal education platform. Clean hierarchy, responsive across devices, accessible markup. Pulan AI needed theirs to communicate enterprise AI data services to both business and technical audiences simultaneously. Standard work, but production standard. Every page had to load fast, rank well, look right on every screen size and connection speed. I stopped thinking of code as something that compiles and started thinking of it as something impatient strangers rely on.
The Deepstate Blog project is where things shifted. A full platform: public-facing blog site and an admin dashboard behind it. Content management, post creation and editing, categories and tags, admin authentication with role-based access, real-time form validation. Not one complex feature but a web of features that all had to cooperate without stepping on each other. An edge case in the admin panel could surface as a broken page for readers. A sloppy API response would cascade into UI bugs in three different places. I spent more time on error states and loading patterns than on the design itself.
When it went live, every assumption I'd made about how people would use it was slightly wrong. Users don't read labels. They click things you don't expect. They discover edge cases that never existed in your testing because they approach the product with completely different mental models than the person who built it.
The most technically demanding project was the 8M Labs Cataloguer. Users upload clothing images, adjust parameters like model attributes and background settings, and get back AI-generated photoshoot-quality results. I built the UI layer wrapping an AI pipeline I didn't build myself. That meant image upload handling with previews, multi-step customization workflows, async requests to services that took unpredictable amounts of time, and graceful fallbacks when they took too long.
Watching a user stare at a loading spinner for eight seconds taught me more about UX than any course on the subject. You can build a polished multi-step form, but if the wait after the final button press feels broken, none of it matters.
The tech stack across projects was modern but not exotic. React, Next.js, Tailwind, CSS modules on the frontend. Firebase, Supabase, PostgreSQL on the backend depending on the project. Various auth configurations. Deployed on Vercel and AWS Amplify with standard CI/CD pipelines.
What I didn't expect to gain was what came from conversations with senior engineers at the agency. Not syntax advice. Structural instincts. How to plan features before opening an editor. How to organize a codebase so it doesn't buckle under its own weight after a few months. How to use AI-assisted tooling to move faster without cutting corners. Those conversations compressed months of trial and error into a handful of pointed suggestions.
Eight months of building for real clients changed how I see this field. I stopped treating projects as technical exercises and started treating them as products people depend on. The distinction sounds obvious until you ship something and a stranger finds the bug you should have caught, and you feel the specific weight of someone else relying on your work.
I'm moving into a Frontend Engineer role at a US-based fintech startup now. Different environment, higher stakes. But the instinct is the same: build things that work, ship them to people who need them, own what happens after.
Links: LinkedIn Blog here