I spent a weekend building Ariva, a tryout platform for CPNS and BUMN preparation. Latihan SKD, direktori instansi, progress tracking, an AI tutor named Claudy. The kind of product that, a few years ago, would have taken me weeks or months of nights and weekends to ship.
This time, I got a working version in roughly one night.
That sounds like a win. And in some ways it is. But the experience left me with a realization that has been sitting in my head ever since: code is cheap now. The bottleneck moved somewhere else entirely.
The Part That Used to Be the Whole Job
If you have been writing software for a while, you remember what personal projects felt like before AI agents and modern tooling got this good. You would sketch an idea, then spend weeks wiring up auth, building CRUD screens, styling components, fixing deployment issues, and rewriting the parts you got wrong the first time.
Now? You describe what you want clearly enough, and a lot of that scaffolding appears fast. Not perfect. Not always production ready on the first pass. But fast enough that "I built this over the weekend" is no longer a flex about your typing speed. It is just... normal.
That shift is real. And I think we are still adjusting to it.
What Actually Took Time on Ariva
Once the app existed, the questions that mattered had almost nothing to do with React components or database schemas.
Ariva is not a generic quiz app. It sits inside a very specific world: government recruitment exams in Indonesia. CPNS SKD has subtests with official formats. TWK, TIU, TKP each have their own rules, timing, and scoring logic. BUMN tests follow a different structure entirely. Users care about real formation data, official sources, and whether your simulation actually resembles what they will face on exam day.
So I found myself learning things I never had to learn when I was "just" an engineer on someone else's product:
- How the SKD selection process works from registration to final results
- What BKN publishes, what it means, and how candidates actually use that information
- Which parts of the exam experience users trust, and which parts make them nervous
- How a tryout product should feel if someone is preparing under real pressure, not just clicking buttons for fun
None of that lives in a prompt. You can ask an agent to generate a quiz UI in an hour. You cannot ask it to understand, on your behalf, what it feels like to stake months of study on a single test format.
That is the work now. Understanding the product domain deeply enough that the software serves the user, not the other way around.
The New Bottleneck: Getting People to Care
Here is the part that made me laugh and also slightly panic.
The app was mostly done. Functional. Deployed. Ready for feedback. And then I hit the wall every engineer founder hits eventually: marketing.
I do not want to open a camera and talk to TikTok. A lot of us do not. We got into this field because we liked building things, not because we wanted to become content creators. But if you want real users, real feedback, and real validation, someone has to put the product in front of people.
That might mean:
- Running ads to test whether strangers will even click
- Building organic traffic through social media (hard, slow, and very public)
- Talking to users directly, which is easier to recommend than to do consistently
As founders, we need feedback fast. Not "eventually when SEO kicks in" fast. Now fast. Did the onboarding make sense? Do people finish a tryout? Does Claudy actually help, or does it feel gimmicky? You cannot answer those questions in a vacuum.
The code being cheap makes this more obvious, not less. When building took months, you could tell yourself the product was not ready to show yet. When building takes a weekend, you run out of excuses.
What "Staying Relevant" Means to Me Now
I used to think staying sharp as an engineer meant keeping up with frameworks, patterns, and the latest toolchain. That still matters. But it is no longer the whole picture.
If you are building something real, even as a side project, you also need to understand:
- The domain. What world does your product live in? What do users already know, fear, and expect?
- The process. Not just the happy path in your app, but the full journey your user is on before and after they touch your product.
- Distribution. How people discover you, trust you, and come back.
- Feedback loops. How you learn quickly without waiting for a perfect launch.
Ariva reminded me that engineering skill still matters. Someone has to decide what gets built, review what the agent produced, fix the edge cases, and connect the product to real user needs. But the differentiator is shifting from "can you build it?" to "do you understand what you are building, and can you get it into the hands of people who need it?"
What I Am Taking Forward
I am not saying code quality stopped mattering. Bad code still creates bad products. I am saying the relative cost of code dropped, and everything around it got louder.
For Ariva, that means spending more time on exam accuracy, user trust, and distribution experiments than on debating component architecture. For me as an engineer, it means reading beyond Stack Overflow. It means talking to users even when I would rather refactor a hook. It means accepting that "I built it" is the beginning of the work, not the end.
We are entering a phase where building is the easy part. Understanding the product, earning attention, and learning from real people: that is the hard part.
And honestly? That might be a good thing. It pushes us to become more than people who write code. It pushes us to become people who ship things that actually matter to someone.
If you are working on a weekend project right now, build it fast. Then go learn the world it lives in. That is where the real project begins.