TL;DR
An engineer who worked on Google Ads infrastructure warns against teams building 'mini-frameworks' on top of shared stacks. These small, opinionated frameworks often introduce new concepts, complicate migrations, and create long-term maintenance and compatibility problems.
What happened
The author, who spent several years on Google Ads infrastructure, describes repeated organizational pain from teams layering small custom frameworks atop shared company technology. In one case their team built an abstraction layer over an internal distributed-programming framework to reduce boilerplate and ease adoption. The migration took far longer than expected — roughly a year for initial adopters — and uncovered edge cases that required constant patching. New code written against the original framework kept adding requirements during the migration, and once the mini-framework was adopted, it introduced unfamiliar concepts and usability issues that slowed development and forced frequent consultations with its creators. The author observed the pattern elsewhere: mini-frameworks typically lack full feature coverage, violate principles that make code easier to change, fragment tech stacks, and often rely on a very small group of maintainers, leaving projects vulnerable if those people move on.
Why it matters
- Mini-frameworks frequently lack feature completeness and compatibility with the original stack, leaving unaddressed edge cases.
- They can violate the 'Easier To Change' principle by modeling only current use cases and depending on fragile implementation details.
- Opinionated abstractions raise cognitive load: new concepts may match the creator's mental model but not others', slowing onboarding and development.
- Small ownership teams increase the risk of abandoned or under-maintained tooling when creators leave, creating long-term technical debt.
Key facts
- The author worked in Google Ads infrastructure for four years and reports recurring problems from mini-frameworks.
- A mini-framework is described as an abstraction built by a small team on top of an org-shared stack that introduces new concepts.
- In the author's team, migrating to a self-made abstraction layer took about a year and required ongoing patching for uncovered use cases.
- After adoption, developers found the mini-framework harder to use than the original framework and required frequent help from its authors.
- Mini-frameworks tend to model current needs and often can't keep pace when requirements change.
- They commonly depend on implementation details of the underlying framework, which can hinder evolution of the original stack.
- Such frameworks increase tech stack fragmentation during partial migrations and are rarely fully retired across large codebases.
- Mini-frameworks are frequently maintained by one or two creators, raising the risk of abandonment when those people leave.
What to watch next
- Rising onboarding time or repeated questions directed at a small group of maintainers — a sign the abstraction may be too opinionated.
- Partial migrations that leave only some services using the new layer, increasing long-term fragmentation and operational complexity.
- not confirmed in the source
Quick glossary
- Mini-framework: A small, team-created framework layered on top of a shared stack that introduces new concepts and abstractions beyond the original tooling.
- Library vs Framework: A library provides reusable code or utilities without introducing new conceptual models; a framework typically defines new concepts and an application structure.
- ETC (Easier To Change) principle: A design principle advocating for writing code that can be modified easily in the future, to accommodate changing requirements.
- DSL (Domain-Specific Language): A specialized mini-language or API designed for a particular problem domain, which can simplify common tasks but may lack flexibility.
Reader FAQ
What is a mini-framework?
A small framework created by a team to wrap an existing shared stack and introduce new concepts; the author defines it as distinct from a library because it adds new terminology or models.
Are abstractions always bad?
No. The author supports abstractions in general but warns against creating frameworks that introduce unnecessary new concepts or are poorly scoped.
Should teams always avoid building frameworks?
The author recommends avoiding mini-frameworks where possible and favoring libraries; if a framework is necessary, link its concepts to concrete business requirements and treat the decision seriously.
Is rebuilding from scratch recommended?
The author suggests that if you must create a framework, starting fresh rather than wrapping an existing framework may avoid some integration problems, but this is presented as a trade-off requiring more discussion and resources.
DEC 24TH, 2025 Avoid Mini-frameworks What is mini-framework? My Story Why mini-frameworks are bad? So, What Should You Do Instead? I work in Google Ads infrastructure in the past four…
Sources
- Avoid Mini-Frameworks
- The Hidden Dangers of Overusing Frameworks
- What are some reasons why people might choose not to …
- Framework Fatigue: When Models Hurt More Than Help
Related posts
- How compilers turn simple loops into closed-form math: a surprising optimization
- Popular Mario and Yoshi Games May Foster Childlike Wonder, Lower Burnout
- How AMD Broke Into CPUs 50 Years Ago With an Intel 8080 Clone