---
url: https://kugie.app/docs/team/about-the-team
title: The team behind Kugie
category: Team & engagement
---

# The team behind Kugie

Kugie is led by two people who came up through Indonesian startups: **Setasena Randata** and **Gerald Akbar**. The studio has grown beyond just the two of us — every account has senior engineers attached, as covered in [we are expensive, and we are worth it](/docs/principles/expensive-and-worth-it) — but the operating DNA of the company is set by the founders, and you will work directly with at least one of us on every engagement.

If you want the longer version of our backgrounds and what the rest of the team looks like, the [about page](/about) goes into more detail. This page exists to explain *how* we work and *why* that matters for the kind of partnership you are buying.

## Trained to be builder and on-call

We came up shipping production systems for Indonesian startups — the kind of operating environment where the engineer who built the system is also the one who gets paged at 2 AM when it breaks. There is no separate "DevOps team" to throw the issue to. There is no "platform team" to escalate to. You built it, you run it, and you fix it.

That experience is baked into how we operate Kugie. The same engineer who designs your architecture also has the on-call rotation for it. We do not separate "delivery" from "operations" — separating them is how systems get built that are impossible to run, and we have seen that pattern enough times to refuse to repeat it.

The visible consequence: when [we monitor everything](/docs/principles/we-monitor-everything), the people watching the dashboards are the people who wrote the code that feeds them. The alerts mean something specific to the person reading them.

## We can give you business context, not just code

Indonesian startups force a particular kind of generalism. The engineer is also the data analyst, also the customer support, also the person renegotiating with the supplier when the integration breaks. You learn the business because there is nobody else to learn it for you.

What this means for an engagement: we can have the business conversation, not just the technical one. When you tell us your unit economics are thin and you need to optimize for fulfillment cost, we can read the P&L, understand which lever moves the needle, and propose where engineering effort should go. When you tell us a launch is coming, we can stress-test the plan against your supplier lead times and your customer support capacity, not just the database.

This is also why we charge what we charge — see [our pricing](/docs/principles/expensive-and-worth-it). The premium is not just senior engineering; it is engineering that understands what business it is operating inside.

## We ship quality code

This is the unglamorous baseline. Type-safe by default. Tests where they earn their keep. Code reviewed by another senior engineer before it hits production. Observability instrumented before the feature ships, not bolted on after the first incident.

We mention it because in the Indonesian market the baseline is often lower, and our work looks expensive compared to teams that skip these steps. We are not the cheapest version of "engineers who write code." We are the version where the code is still serving you cleanly two years later.

## What this means for your engagement

You get builders who treat your business as their business for the duration of the engagement. You get on-call discipline because we cannot offload it. You get the business-context conversation because we have lived inside that conversation before. And you get the code quality because we have been burned by the alternative often enough to refuse it.

If this sounds like the team you want, the next step is on [how to engage](/docs/team/how-to-engage).