Building SaaS in Makati: A Founder's Playbook
SaaS development in Makati looks different from SaaS development anywhere else in the Philippines, and not because the code is different. It is because of who is in the room. Makati founders are usually one or two degrees away from a corporate buyer, a bank, an insurer, a logistics group, or a family business with real revenue. That proximity changes the shape of the product you should build, the order you should build it in, and how long you can afford to spend before someone pays you. This is the playbook we give founders who come to us from the CBD, based on eight years of building software from Cavite for clients in Makati, BGC, and abroad.
What SaaS Development in Makati Actually Requires
The single biggest advantage a Makati founder has is distribution. You can usually get a meeting with your first five customers before you write a line of code. The single biggest trap is that those five customers are enterprises, and enterprises will happily describe a product that takes two years to build and serves exactly them.
So the first job in SaaS development in Makati is not technical. It is deciding which parts of what your early buyers describe are actually a product and which parts are consulting work wearing a product costume. In practice that means writing down the workflow you are replacing, naming the single metric that improves when you replace it, and cutting everything that does not move that metric in version one.
The second requirement is compliance literacy. If your buyers are in financial services, healthcare, or anything touching payments, your architecture inherits their obligations. Data Privacy Act requirements, audit logging, role separation, and data residency questions come up in procurement, not at launch. Building them in from sprint one costs very little. Retrofitting them after your first enterprise security review costs a great deal.
Timelines: What a Realistic Build Calendar Looks Like
Founders usually arrive with a timeline shaped by a funding deadline or a conference date. Here is what we see hold up in reality.
A focused internal tool or a single-workflow SaaS with one or two user roles, authentication, billing, and a working admin panel is roughly a two to three month build. A multi-tenant B2B platform with role-based access, reporting, an integration or two, and a customer-facing dashboard is closer to three to five months. Anything touching payment rails, KYC, or regulated data adds time that is mostly spent waiting on other people, not writing code.
What actually makes builds slip is rarely engineering speed. It is unresolved product decisions. Every week a founder cannot decide whether the pricing model is per-seat or usage-based, the schema, the billing logic, and half the UI stay in limbo. The fastest builds we run are the ones where the founder answered the hard questions in a written strategy doc before sprint one, which is exactly why we insist on one.
Studio, Agency, or In-House Team?
There are three common paths for MVP development in Manila and Makati, and each fails in a specific way.
Hiring in-house first gives you full control and the highest long-term ceiling. It also means you are recruiting senior engineers in the most competitive talent market in the country before you have a product to recruit them to. Most pre-revenue founders spend four months hiring and then discover their first hire was the wrong shape for the problem.
A traditional agency is fast to start and delivers to spec. The failure mode is that they deliver exactly to spec. If your spec was wrong, and first specs usually are, you get a beautifully executed version of the wrong product.
A product studio sits between the two. You get a team that has shipped this kind of thing before, that pushes back on the brief, and that treats the architecture as something you will own and extend. Some studios will discuss equity or blended arrangements. Be careful there: equity-heavy deals sound founder-friendly, but they also reduce the studio's urgency to hit a date. We prefer fixed scope, fixed fee, and full code ownership on your side from day one, because it keeps the incentives boring and legible.
Whichever path you pick, insist on three things in writing: you own the repository, you own the cloud accounts, and you own the domain. Founders who skip this are the ones who message us a year later asking how to recover a product they paid for.
Why We Push Founders Toward MSP Instead of MVP
The MVP framing was built for markets where you can burn a year learning and raise again on the learning alone. Most Philippine SaaS founders do not have that runway. They have one shot, a small round or their own savings, and a first cohort of customers who will not come back for a second look if the first version embarrasses them.
That is why we build a Minimum Scalable Product instead. Same discipline about feature count, completely different standard for the foundation underneath. Production-grade data model, real authentication and role separation, infrastructure that survives a spike, monitoring that tells you what broke before a customer does. Minimal features, non-minimal foundation.
The practical difference shows up in month nine. An MVP that found product-market fit usually needs a rebuild, which means your best momentum is spent on work that produces no new value for customers. An MSP that found fit gets extended. You keep shipping.
Budget Ranges and What Moves Them
We do not publish exact figures for hypothetical projects, because every project is scoped individually and a number without a scope is worse than no number. What we can give you is directional shape.
A tight single-workflow SaaS with billing and one role tends to land in the low six figures in pesos. A multi-tenant B2B platform with reporting, integrations, and multiple roles typically starts in the low six figures and climbs from there depending on how many of the cost drivers below apply. Ongoing costs after launch, meaning hosting, monitoring, third-party services, and a maintenance retainer, usually run in the low five figures monthly for an early-stage product.
The variables that move the number most:
- Number of distinct user roles. Each one is its own set of screens, permissions, and tests.
- Integrations. Payment gateways, GCash and Maya flows, QR Ph, accounting systems, and government endpoints all add time you do not fully control.
- Compliance scope. Audit trails, consent management, and data handling requirements are cheap early and expensive late.
- Mobile. A responsive web app and a native or React Native companion are two different projects, not one project with a checkbox.
- Design depth. A functional interface and a differentiated product experience are separated by weeks of design work, usually worth paying for if you sell to consumers.
If you want a second opinion on scope before you commit budget, that is a short conversation and a useful one. You can read how we structure builds on our product development and minimum scalable product pages.