Philippine founders keep everything private because they're afraid of two things: competitors copying them and investors seeing failures. Both fears are real and both are overestimated. The competitor who can build your exact product by reading your public posts is already ahead of you. The investor who avoids founders who fail isn't worth impressing. Building in public solves a different problem — and the audience you might grow is the secondary benefit, not the point.
By Diosh Lequiron, PhD, MBA, CSM — President & CEO, HavenWizards 88 Ventures OPC Last updated: May 9, 2026
The Problem Building in Public Actually Solves
Building in public started as an audience-building strategy: share your startup journey, grow followers, use the attention for distribution. That framing is accurate but incomplete.
The mechanism that actually makes build-in-public useful is articulation pressure. When you commit to writing publicly about what you built this week, you are forced to have an answer. You cannot say "we made progress" and move on. You have to name the specific thing that shipped, the specific thing that didn't, and the specific thing you're changing because of what you learned.
This pressure has a compounding effect on decision quality. Founders who build in private can run quarter after quarter without clearly articulating whether their core assumption is working. Founders who build in public have to say it out loud every week — which is when they discover that they've been avoiding the answer.
At HavenWizards 88, our Build Log (publicly accessible at /build-log) documents real deployments: the cms_build_log_entries table has real entries by date with real outcomes. Some entries are "this worked, here's why." Some are "this didn't work, here's what we changed." The entries exist because we write them, not because we have an audience requiring them. The audience comes later.
What to Share vs. Keep Private
The fear that builds in public equals sharing everything is wrong. The framework is simple:
Share freely:
- What you shipped (specific, not vague)
- What you measured (the number, not "we saw improvement")
- What you learned (the insight that changed your plan)
- What you're building next (directional, not detailed)
- Failures, as long as you include what you changed
Keep private:
- Customer identities (never share client details without permission)
- Business terms (pricing, equity splits, partnership agreements)
- Operational details that give competitors a specific technical blueprint
- Personnel decisions
The "competitors will copy me" fear collapses when you apply this framework. What you're sharing is outcomes, learnings, and direction — not source code, not product architecture, not growth playbooks. Sharing that you achieved a 73% reduction in operations work doesn't tell anyone how to replicate your AI automation stack. Sharing that n8n + Supabase + custom prompts is your stack tells them the direction, not the implementation.
Why This Works Specifically for Philippine Founders
The build-in-public model travels well to the Philippines for three structural reasons:
1. The Philippine startup ecosystem is small and relationship-driven. Public documentation of real outcomes builds trust faster than any marketing claim. When a potential partner sees six months of specific build entries — including the failures — they have evidence of how you operate that no pitch deck provides.
2. Filipino founders are systematically underrepresented in global startup conversations. Building publicly in an English-language medium with Filipino context signals (local venture names, peso costs, Philippine-specific regulatory notes) fills a genuine content gap. The SEO upside is real — no competitor in this niche is documenting the Philippine founder experience at depth.
3. The accountability pressure is higher in resource-constrained environments. When you're operating on limited runway, the cost of a lost month is higher than in well-funded startups. Building in public creates a weekly forcing function that expensive OKR systems try to create artificially.
How to Start (Not a Full Content Strategy)
The biggest failure mode for build-in-public adoption is treating it as a marketing project requiring planning, scheduling, and a content calendar before the first post goes out.
Start with one rule: one post per week, documenting one specific thing that happened.
Not a thread. Not a case study. One post. Three formats work:
The shipped post: "This week we deployed [specific thing]. Before: [metric]. After: [metric]. What made it work: [specific reason]."
The failed post: "We tried [specific thing]. It didn't work because [specific reason]. We changed [specific thing] as a result."
The learning post: "We assumed [specific thing]. The data showed [specific thing]. We changed our plan to [specific thing]."
That's it. The compounding effect comes from consistency, not from any individual post's reach.
At HW88, our public Build Log started as internal documentation that we made public. The effort to make it public was near-zero because the internal documentation already existed. If you're documenting decisions internally (even in Notion or a private Slack), the marginal cost of making it public is one editing pass.
Frequently Asked Questions
Won't competitors use my public posts to copy my strategy? The risk is real but narrow. What's copyable from public posts — the direction, the tools, the framework — is not the hard part of your competitive advantage. The hard part is execution, relationships, and institutional learning. A competitor who can read six months of your posts and replicate your position was never behind you in the first place.
Does building in public work if I have a very small audience? Yes. The accountability mechanism works with zero audience. The discipline of writing a specific weekly post has the same effect whether five people read it or five thousand. The audience is a byproduct, not a prerequisite.
How do I handle public posts about things that didn't work during fundraising? Investors who avoid founders with documented failures are selecting for founders who either haven't tried hard things or who hide their failures. Neither is the investor you want. More useful: frame failed experiments with the learning and the change. "We tried X, it didn't work, here's what we changed" reads as operational maturity, not weakness.
What platform should I use for building in public in the Philippines?
LinkedIn has the highest professional audience density for Philippine founders. X (Twitter) has global startup audience reach. Your own website/blog has the best long-term SEO value. We use all three but start content on the website (at /build-log) and distribute to social platforms. Don't start with a platform decision — start with the practice.
Related Reading
HW88 Build Log → — real deployment entries from across the venture portfolio, updated continuously.
AI Automation for Philippine Startups → — the 73% ops reduction that started as a build-in-public documentation practice before it became a strategy.
Diosh Lequiron is the founder of HavenWizards 88 Ventures OPC. He has been documenting the HW88 build process publicly since 2024. View the portfolio → Read the Build Log →