ARCHITECT
Currently building at GELabs LLC
Michael “Mikez” Garcia

I don't just ship
products. I design the
strategies that ship them.

CTO  ·  Systems Architect

Architecture plans. Team composition. Technology selection. Execution discipline. Most founders ship products. I design the decision layer that keeps the product shippable as it scales. Currently doing that at GELabs for three active ventures — with care as the operating principle.

How I build →Work with me
3+
Active ventures
6y
Building in prod
4
Disciplines owned
◇ GELABS.SYS / v1.0LIVE
Mikez Garcia portrait
◇ QUEZON CITY, PH
MG
Mikez Garcia
CTO · GELABS LLC
01 — The discipline

Strategy is the work.
Shipping is the receipt.

A product is only as scalable as the decisions that shaped it — made on day one, under constraint, with incomplete information.— Operating note · GELabs

Most technical founders confuse building with strategy. They ship the first thing that compiles, hire the first people available, pick tools they already know — and call that execution. Six months later, they're rebuilding.

I operate differently. Before a line of code gets written, I'm working through the architecture plan, the team shape, the technology trade-offs, and the execution model. The code is the easy part. The decision layer underneath is where projects live or die.

That's the discipline I bring as CTO and systems architect: turning ambiguity into a concrete plan, a concrete team, and a concrete path to shipped — repeatedly, across ventures, with care at every call.

02 — How I build

Four pillars. Applied before anything gets built.

Every venture at GELabs gets run through the same four-pillar framework. Not as theory — as the literal sequence of decisions made before a sprint zero.

PILLAR.01

Architecture planning.

I draw the system before the team writes the code. Data flow, service boundaries, failure modes, scale pressure points — all mapped before the first PR.

System-level diagrams (DFDs, ERDs, service maps) before sprint zero.
Failure modes identified upfront, not discovered in production.
Every subsystem has a defined contract — inputs, outputs, ownership.
Architecture docs live in repo, not in my head.
PILLAR.02

Team composition.

The right team is shaped by the problem, not the hiring market. I design the org chart the same way I design the system — around the actual work.

Role shape defined by system boundaries, not job titles.
Hire for judgment and shipped history — not certifications.
Know when to build with 1, 3, or 10 — and when to stay at 1.
Every teammate owns an outcome, not just a task.
PILLAR.03

Technology selection.

Stack choices are strategic commitments. I pick for constraints and boring-reliability — not for what's trending on Hacker News this week.

Tools evaluated against actual load, team, and budget — not hype.
Prefer boring technology that ships over novel tech that impresses.
Every stack choice has a documented rationale and exit path.
AI, MCP, and real-time infra adopted where leverage is real.
PILLAR.04

Execution discipline.

The strategy dies when shipping pressure hits — unless the execution model protects it. I build review loops, decision gates, and ownership maps that hold the plan intact.

Weekly architecture review — drift gets caught early, not after launch.
Decision logs so future-me knows why past-me made a call.
Fast iteration — but from a fixed set of principles, not vibes.
Metrics tied to outcomes. If it doesn't move, it didn't matter.
03 — Decision frameworks

Every pillar runs on a question.

Architecture without a framework is just aesthetic. Here's the actual cognitive pattern — the questions asked before every technical or organizational decision.

01
Will this decision still make sense when we're 10× the size?
Every architecture call gets this test. If the answer is no, the decision is a liability dressed up as a choice. Short-term convenience that breaks at scale isn't speed — it's debt with a delivery date.
02
What's the reversibility costif we're wrong?
Two-way doors get made in minutes. One-way doors get slept on. I move fast on reversible decisions and deliberately slow on irreversible ones. Confusing those two is how startups die.
03
Who owns the outcome — not the task?
Tasks get assigned. Outcomes get owned. Every system I design has a clear accountability map: when it breaks, there's one person who's supposed to care about it, and they know it. Ambiguity in ownership is the root of every post-mortem I've ever written.
04
Does this tool earn its complexity?
Every added dependency, framework, or service is a tax. It must pay for itself in leverage. Postgres over a custom cache, Firebase over self-hosted auth, Railway over Kubernetes — these are strategy calls, not laziness. Complexity should be proportional to the problem.
05
If I stepped away for a month, would the system hold?
This is the ultimate systems-thinking test. If the answer is no, I haven't designed a system — I've designed a dependency on myself. The best architecture is one that makes the architect optional, without making them absent.
04 — Proof in production

The strategy runs. Three ventures, three sectors, one operating model.

These aren't case studies. They're proof the four pillars hold when the shipping pressure starts. Each one I architected, staffed, and chose the stack for — from day zero.

₱SUCCESS97.6%
FINTECH · DISBURSEMENTLIVE

GoldenPay

Enterprise disbursement platform

Bulk & single payouts, real-time transaction reporting, wallet-based disbursement flow. Built for operators handling ₱37M+ in monthly transactions.

RoleSystems architect — architecture, stack selection, team shape
ONLINE
LPG LOGISTICS · MULTI-APPLIVE

BidaGas Portal

3-app LPG distribution platform

Operator dashboard, customer mobile app, rider desktop. End-to-end LPG distribution system — orders, dispatch, inventory, earnings, in one operating model.

RoleCTO & architect — multi-surface system design, team structure
MEMBERS08 LIVE
MOBILITY · NAVIGATIONPUBLIC BETA

ConvoyFriends

Group-first nav on HERE SDK

Real-time convoy sync, coding-compliance routing, toll awareness — built for how Filipinos actually drive. YC S26 application in-flight.

RoleCo-founder & CTO — SDK integration, infra, architecture
05 — Operating stance

Leadership is an execution pattern, not a title.

Hands-on. In the system. Always.

I don't manage from the architecture-review meeting. I'm in the code, the spreadsheet, the Slack thread, the client call — whichever one the problem needs today. Strategy without proximity is just a slide deck.

I've led shift-based ops across four departments at Ecosyscorp. I've built the Taglish announcement that actually lands with the team. I've run transition-hour overtime calculations at midnight. All of that is leadership too— and the founders who don't know that are missing the layer where culture actually happens.

Under constraints, I get sharper. The best systems I've shipped were built under resource pressure, and that's not a coincidence. Constraints force clarity about what actually matters. Abundance is where scope creep lives.

◇ The operating stance
  • Decisions in hours, not weeks. Reversible ones in minutes.
  • Every system has an owner. Ambiguity is the bug.
  • Clarity beats consensus. Every time.
  • If the metric doesn't move, the work didn't matter.
  • Hire for judgment. Manage for accountability.
  • Boring technology that ships > novel technology that impresses.
  • Care about the work. Or don't do it.

I'm not here to build apps.
I'm here to build systems
that move industries.

If you're building in Southeast Asia, betting on real-world systems, or looking for a CTO who designs the strategy — not just the stack — let's talk.

Email me directly →Partner with GELabs