# Kugie — full documentation > A single-file dump of every page under /docs, in manifest order. Each > section begins with a YAML-style header naming the canonical URL so > facts can be attributed to their source. Generated from the same MDX > that powers https://kugie.app/docs. --- url: https://kugie.app/docs/principles/expensive-and-worth-it title: We are expensive, and we are worth it category: Operating principles --- # We are expensive, and we are worth it We charge more than most Indonesian vendors. Our [kickoff pricing](/pricing) is public; monthly engagement scales with the system we are operating for you. If our pricing surprises you, we are probably not your team. That is fine — there are cheaper options in Indonesia and they may serve you well. This page exists so you understand what the premium is for, and decide for yourself whether the trade is worth it. ## First-party cloud only We deploy to AWS, GCP, and Alibaba Cloud. The only exception is Cloudflare for DNS and edge — because it is the most reliable resolver and CDN available today. We do not use cheap VPS providers, shared hosting, or unverified regional clouds. When you ask us why your system has been up for 18 months without an incident, this is the answer. Reliability compounds. The cost of the cloud bill is a rounding error against the cost of one bad outage during a launch. If you need us to deploy onto infrastructure we do not trust, we will decline. That is covered separately in [who we don’t work with](/docs/fit/who-we-dont-work-with). ## Senior engineers only You will not be billed for junior engineers learning on your project. Every person on your account has shipped production systems before — usually for years, usually under load. Indonesian software vendors often hide their margin in headcount: quote a senior rate, staff with juniors, supervise loosely. We do not do this. The people on your standup are the people writing the code. This is the second-biggest line item in our pricing. We think it is the most important one. ## No headcount markups We tell you exactly who is working on your account and what they do. If you want to verify it, attend our standup. We invite you to our internal Slack as a guest specifically so you see this in real time — see [how we embed](/docs/principles/we-embed) for the full picture. There is no hidden bench, no "blended rate" that obscures who is doing the work. The line items are people, the people are named, and the people are real. ## What this costs The current numbers live on the [pricing page](/pricing). They are public on purpose: we would rather lose the deals we are not the right team for, before either of us spends time on a call. If the number works for you, [start a conversation](/contact). --- url: https://kugie.app/docs/principles/vertical-exclusivity title: One vertical, one client category: Operating principles --- # One vertical, one client This is the rule we get asked about most, and it is absolute. ## How we define a vertical We define a vertical as **a business model with a specific way of generating profit** — not an industry. Coffee roastery and direct-to-consumer cafe are different verticals because they make money differently: one sells beans to other businesses, the other sells cups to walk-in customers. Two direct-to-consumer cafes are the same vertical, and we will not work with both at the same time. The test is "do these businesses make money the same way from the same customers?" — not "are they in the same industry?" A wholesale grocer and a delivery-only ghost kitchen sit in different verticals even though both are food. A flagship retail brand and the same brand’s wholesale arm are different verticals too. ## What this means for you If you are already a Kugie client, you can be certain we are not building the same system for your competitor. We will not learn from your operations and apply those lessons to someone selling the same thing to the same customer. If you approach us and we already serve a competitor in your vertical, we will tell you on the first call. No exceptions, no NDAs around it, no "we will keep the teams separate." We say no. ## Why we hold the line This caps our revenue. We are aware. We think it is worth it. The alternative — serving multiple competitors in the same vertical with "chinese walls" — is what large agencies do. It works on paper. In practice, the institutional knowledge inevitably leaks into the next pitch, the next architecture decision, the next hire who used to work on the other account. Our clients ship faster because we know their business deeply. We cannot offer that depth honestly to two competitors at once. ## How to verify If you want to know whether we already serve someone in your vertical, ask on the first call. We will tell you — including the name, if they have consented to be named, or at least enough detail that you can decide. The list of [who we work with](/docs/fit/who-we-work-with) explains the broader pattern. --- url: https://kugie.app/docs/principles/async-and-fast title: We work asynchronously, and we work fast category: Operating principles --- # We work asynchronously, and we work fast Indonesian business culture defaults to meetings. We don’t. ## Our default is async Decisions happen in writing — in Linear, in Slack threads, in documents you can re-read. We meet when meeting is the only way to move forward, not as a status ritual. The reason is not philosophical. It is operational. Writing forces clarity. A decision in a Slack thread can be searched, audited, and shared with the next person you onboard. A decision in a meeting evaporates unless someone takes notes, and the notes always lag the actual decision. We optimize for the durable artefact. If your culture requires us in daily video calls as the default mode of work, we are a poor fit. That disqualifier is listed explicitly in [who we don’t work with](/docs/fit/who-we-dont-work-with). ## Acknowledgement is fast. Resolution is honest. | Severity | Acknowledgement | Resolution | | -- | -- | -- | | Urgent (system down, revenue impacted) | Under 1 hour, 24/7 | Under 24 hours, including weekends | | High priority (degraded, blocking) | Same business day | 2–3 days | | Standard | Within 1 business day | Scoped per engagement | We separate acknowledgement from resolution because they are different promises. "We see this and we are on it" is something we can guarantee in minutes. "We will have a fix in your hands" depends on what the fix is — and we will not promise a timeline we do not believe. ## We will not start work without a defined timeline If you do not know when you need it, we do not know what we are committing to. We will help you set the timeline — but we do not begin until it exists. Open-ended retainers without defined outcomes erode quality on both sides. The work drifts, the priorities shift, and the relationship turns into a holding pattern. We would rather front-load the conversation about deadlines than back-load the disappointment about delivery. ## We work from data and research, not intuition Before we write code, we research your business, your competitors, and the systems you already have. Expect a discovery period at the start of every engagement. Expect us to disagree with you sometimes. That is what you are paying for. We will explain our reasoning, we will show our work, and we will defer when you have context we don’t — but we will not say "sure, no problem" to a decision we think is wrong. --- url: https://kugie.app/docs/principles/we-embed title: We embed in your team category: Operating principles --- # We embed in your team We are not a project shop. We do not take a spec, disappear for three months, and hand you a codebase. We embed. That means we are in your business the same way an internal team would be — with the same context, the same access, and the same skin in the game. ## What embedding looks like in practice - **We meet you in person at kickoff.** If you are in Indonesia, we come to you. The first meeting is on your turf, not a Google Meet. - **We join your internal meetings when you invite us.** Weekly leadership, ops standups, marketing reviews. We strongly encourage it — the more context we have about how your business runs, the better the systems we build. - **We invite you to our Slack as a guest.** You see our alerts, our deployments, and our incident channels in real time. Nothing is filtered. If something is on fire, you watch us fight the fire as it happens. - **We join your WhatsApp groups.** Indonesian operations actually happen on WhatsApp — the suppliers, the team chats, the stores. We need to be where the decisions are made, not three layers removed. ## Helicopter view and detail view We work both. We care about your unit economics, your hiring plan, and your supplier relationships — because all of those decisions become technical decisions eventually. A pricing tier change becomes a database migration. A new payment provider becomes a webhook handler. A change in supplier becomes a CSV ingestion job. If we only know the technical layer, we miss why the work matters. So we learn the business layer too. This is also why we can have business-context conversations, not just engineering ones. See [the team behind Kugie](/docs/team/about-the-team) for why that matters. ## We are not your vendor We are your tech team. The distinction matters because vendors work to the spec; teams work to the outcome. When the spec is wrong, a vendor builds the wrong thing on schedule. A team pushes back. That is the relationship we want. If you want a vendor — someone who builds exactly what you ask, no questions — there are cheaper options in the market. We will not be the cheapest version of that, and we will not be the most pliable. We will be the team that asks the second question. --- url: https://kugie.app/docs/principles/our-tools title: Our tools are your tools category: Operating principles --- # Our tools are your tools Big tech runs on open source. Netflix, Uber, and PayPal handle massive web traffic on MySQL and Node.js. Meta built PyTorch and Google built TensorFlow; the rest of the industry now trains models on them. Cloud infrastructure is orchestrated through Kubernetes and Ansible. The pattern repeats at every scale. There are good reasons. Open-source software is customizable, your security team can audit the code for vulnerabilities, and you are not paying license fees that compound as you grow. At scale, the total cost of ownership is almost always lower than the proprietary equivalent. We operate on the same conviction. The stacks we deploy for you are built from the best open-source tooling we know — not proprietary wrappers we mark up. ## We are not a tools-setup vendor This matters for one specific reason: we do not make money on the setup. We do not buy a SaaS seat, resell it to you at a markup, and pocket the margin. We do not ship a "Kugie Analytics" wrapper around a tool you could have run yourself. Your infrastructure should be yours, and the tools running on it should be ones you can keep running after we are gone. Concretely, the stack we standardize on: - **Metabase** — open-source business intelligence. Deployed to your data, owned by you. - **BigQuery** — Google's warehouse when your analytics workload outgrows Metabase alone. You pay Google directly; we do not sit in the billing path. - **Grafana stack** — Loki for logs, Prometheus for metrics, Grafana for dashboards. The same stack [we monitor everything](/docs/principles/we-monitor-everything) with, all open source, all deployed on your cloud. - **Postgres, Redis, Node.js, Next.js, Python** — the building blocks for the systems we build for you. Standard, durable, not exotic. The skills to maintain them exist in the broader market — you are not hostage to anyone, including us. When proprietary actually is the right answer, we will tell you. Fortune 500s do not run their accounting on open-source software, and there is a reason core ERP, HR, payroll, and legal tend to live on Oracle, NetSuite, or Workday — those are categories where the dedicated enterprise support is worth what it costs. We will not invent open-source heroics when the real answer is "buy the licensed product." But that is the exception, and we make the case for it explicitly when it comes up. ## We open source what we build We have open sourced two of our own products: - **[Summit](https://summitfinance.app)** — invoicing and financial management. The same tool we use to run our own engagement billing. Open source on GitHub for self-hosting or contribution. - **[Swivel](https://swivel.id)** — agentic CRM and loyalty for direct-to-consumer brands. Customer profiles, segmentation, loyalty programs, and an agent layer that automates the messages your team would otherwise hand-craft. Also open source. While you are embedded with us, you get full access to our hosted versions of both — no SaaS bill, no seat license, no per-message metering. If the engagement ends, or you decide to host them yourselves, the code is public. You are not locked in. This is intentional. Open sourcing the tools we live in keeps us honest about quality — the code is reviewable by anyone — and it is how we contribute back to the open-source ecosystem we depend on every day. ## The full stack you operate on When you are with Kugie you operate with the same tooling as a venture-backed startup, without paying SaaS bills for each one. The pattern is: - **Open source by default** for the layer we control: business intelligence, observability, application runtime, databases. - **First-party cloud** for compute and storage — AWS, GCP, Alibaba Cloud — for the reasons covered in [we are expensive, and we are worth it](/docs/principles/expensive-and-worth-it). - **Proprietary** where it is genuinely the better answer — payment processors, accounting, payroll, transactional email, sometimes search. Named, justified, billed to you directly. You get a stack that the largest tech companies in the world would recognize, configured for the scale your business actually runs at, and ownable the day you outgrow us. --- url: https://kugie.app/docs/principles/we-monitor-everything title: We monitor everything, and we tell you first category: Operating principles --- # We monitor everything, and we tell you first Every system we operate has the [Grafana stack](/docs/principles/our-tools) deployed from day one. We instrument logs, metrics, and traces before we ship. This is the most boring principle on this list. It is also the one that pays for itself every quarter. ## You hear about incidents from us, not from your customers This is the operating standard. If your checkout starts erroring, we should be paging ourselves before the first customer email lands. The alternative — your ops lead messaging us "hey is the site down?" — means we missed the window where we could have fixed it quietly. ## What you get on an urgent incident For every urgent incident, you get: - **Acknowledgement within 1 hour, 24/7.** This is the same SLA we publish on [async and fast](/docs/principles/async-and-fast). - **A status update every 2 hours until resolved.** Written, in the incident channel, so anyone on your team can read the history. - **A written postmortem within 5 business days.** Including root cause, what we did to mitigate, and what we are changing so it does not happen again. ## We do not hide incidents There is a temptation — especially for vendors trying to look reliable — to downplay incidents, batch them into "minor issues," or fix them quietly without telling the client. We do the opposite. Every incident with customer impact gets surfaced, written down, and shared. This is partly principle and partly self-interest. If we fix an issue without telling you, we miss the chance to align on whether the underlying architecture decision was right. The postmortem is where we earn or lose trust. ## We do not blame upstream providers If AWS goes down and our architecture did not tolerate it, that is on us. "The cloud was down" is not an incident excuse. It is a design constraint we should have planned for. Multi-region failover, queue durability, retry-with-backoff — these are the things our pricing pays for. Blaming AWS for an outage we could have absorbed is admitting we did not do the work. This does not mean every system is multi-region. It means that for every system, we have made an explicit decision about how it behaves when a dependency fails — and that decision is documented somewhere you can read. --- url: https://kugie.app/docs/fit/who-we-work-with title: Who we work with category: Fit --- # Who we work with We work with **lifestyle brands** — businesses selling to consumers who care about the brand, not just the product. Coffee. Food and beverage. Fashion. Hospitality. Wellness. Hobby retail. The shape of the business varies, but the customer relationship is recognizable: the customer is choosing this brand over a generic alternative because the brand means something to them. ## The pattern we serve well You have a brand. You have customers. You have operations. You want to use technology to grow margin and reduce chaos. We will: - **Analyze your customers** — segments, lifetime value, behavior over time. So your marketing, loyalty, and product decisions are based on data, not guesses. - **Optimize your operations** — inventory, fulfillment, scheduling, supplier comms. The boring backbone that determines whether a busy day is profitable or chaotic. - **Automate the boring parts** — the data entry, the report generation, the manual customer follow-ups. Anything that someone on your team is doing repetitively that a system could do. - **Build the systems that let you scale without hiring linearly.** Headcount is the most expensive way to grow. We are the alternative. ## Why we are good at this Coffee shops, restaurants, fashion brands, and hospitality businesses share a structural pattern: customer-facing front-of-house, operations-heavy back-of-house, and a brand layer on top of everything. The technical problems repeat — POS integrations, inventory sync, loyalty programs, customer comms, ops dashboards. We have built these systems many times. The first version is rarely the cheapest, but every version after the first is faster than the market because we are not learning the domain from scratch. ## What this excludes If your business does not look like the pattern above — for example, you sell software, or you sell to other businesses through a sales team, or your customer relationship is purely transactional — we may not be the best fit. The clearest version of those disqualifiers lives in [who we don’t work with](/docs/fit/who-we-dont-work-with). ## How to test the fit The fastest way to know is to [start a conversation](/contact). Tell us about your brand, your customers, and the systems you currently run. We will tell you on the first call whether we think we can help, and we will tell you if we think someone else would serve you better. --- url: https://kugie.app/docs/fit/who-we-dont-work-with title: Who we don’t work with category: Fit --- # Who we don’t work with We are clear about this so you do not waste your time or ours. The five cases below are the ones we decline reliably. If your situation fits any of them, we are not your team — and we would rather tell you on this page than at the end of a sales process. ## We don’t build products for product companies If your company *is* a software product looking for a co-founder team or a build partner to ship your SaaS, we are not your team. We serve brands that *use* software, not brands that *sell* software. This sounds like a small distinction. It is not. Building a software product means optimizing for a different user, a different pricing model, a different growth motion, and a different operating cadence than the lifestyle brands we serve. We would do it badly. There are excellent product engineering studios in Southeast Asia for this — find them. ## We don’t work on unreliable infrastructure If you need us to deploy to a cheap shared host or a VPS provider we do not trust, we will decline. The reliability we promise — see [we monitor everything](/docs/principles/we-monitor-everything) — is incompatible with the infrastructure you would be asking us to use. We commit to "the system is up" as an outcome, and we cannot commit to that on hardware we do not trust. This is also the basis of our [pricing](/docs/principles/expensive-and-worth-it): first-party cloud is non-negotiable. ## We don’t run synchronous-heavy engagements If your culture requires us in daily video calls as the default mode of work, we are a poor fit. We meet when meeting is the right tool. Otherwise we ship. This is not us being precious about meetings. It is operational. Our team operates across multiple engagements asynchronously, and a culture that requires constant synchronous attendance breaks that model. The trade we are offering is: faster delivery, written decisions, fewer status meetings. If your team needs the opposite, we are not the trade you want. The full breakdown is on [async and fast](/docs/principles/async-and-fast). ## We don’t take engagements without a timeline Open-ended retainers without defined outcomes erode quality on both sides. The work drifts, the priorities shift, and the relationship turns into a holding pattern. We always work toward something specific — a launch, a quarter, a measurable outcome. If you do not know when you need the work, we will help you set the timeline. But we do not begin until it exists. ## We don’t compete with our existing clients If we already serve your vertical, we say no and we mean it. The full reasoning is on [vertical exclusivity](/docs/principles/vertical-exclusivity). Short version: we tell you on the first call, no NDAs around it, no "separate teams." ## If we say no If you contact us and we decline, we will tell you why. Where we can, we will point you toward someone better suited — a friend of the studio, a different agency, a different kind of help entirely. We would rather you find the right team than the wrong one in our seat. --- 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). --- url: https://kugie.app/docs/team/how-to-engage title: How to work with us category: Team & engagement --- # How to work with us If you have read this far and we sound like the right team, [start a conversation](/contact). The form on that page goes to a human at Kugie within one business day. What follows is the honest version of what happens between "I sent the message" and "the team is embedded." ## 1. The first conversation The first call is 30 minutes. We will ask you about: - **Your brand.** What you sell, who buys it, what makes you different from the businesses across the street. - **Your current systems.** What you run today — point of sale, website, CRM, finance — and what is breaking or limiting you. - **What you are trying to build.** The change you want to see in the next 6–12 months and why it matters now. You should ask us about: - **Whether we already serve your vertical.** Per [vertical exclusivity](/docs/principles/vertical-exclusivity), we will tell you on this call. If we do, the conversation ends here and we will point you elsewhere if we can. - **Pricing.** It is already on the [pricing page](/pricing), but the call is the place to talk about what the number means for your specific situation. - **Anything in these docs you want us to expand on.** Especially the principles that surprised you. ## 2. The qualification After the first call, we make a decision internally — usually within a few days — about whether the engagement is one we can do well. We are looking for: - **Vertical clearance.** No competitor in our existing book. - **Pattern match.** Your business looks enough like the kind of business we serve well that we have a real edge, not just a willingness to take the work. - **Cultural fit.** You are comfortable with an async-default working style. See [async and fast](/docs/principles/async-and-fast). - **Defined timeline.** You know roughly when you need the work, or you are willing to define that with us before kickoff. If we say yes, we propose a kickoff date and a scope document. If we say no — for any of the reasons in [who we don’t work with](/docs/fit/who-we-dont-work-with) — we tell you why, and we try to point you toward someone better suited. ## 3. The kickoff If we both decide to proceed: - **We meet you in person.** If you are in Indonesia, we come to you. The first kickoff is on your turf. - **We do a discovery period.** Before we write production code, we research your business, your competitors, and the systems you already have. Expect this to take longer than you would guess. The decisions made here are the ones that matter for years. - **We instrument observability from day one.** Logs, metrics, dashboards. See [we monitor everything](/docs/principles/we-monitor-everything). - **We onboard you to our tools.** Summit, Swivel, Metabase, Grafana — whichever are relevant. See [our tools are your tools](/docs/principles/our-tools). - **We add you to our Slack as a guest, and join your WhatsApp groups.** This is the embedding — see [we embed in your team](/docs/principles/we-embed). ## 4. The engagement, ongoing Standups, written decisions, async by default, in-person when it matters. SLAs as published on [async and fast](/docs/principles/async-and-fast). Incidents acknowledged, status updated, postmortems written. We grow as you grow. That is the only way this works. ## If you are still deciding Read the [operating principles](/docs/principles/expensive-and-worth-it) first if you have not. If pricing is the question, see the [pricing page](/pricing). If you want the longer story of who we are, the [about page](/about) goes further than [the team behind Kugie](/docs/team/about-the-team). When you are ready, [start a conversation](/contact).