One Engineering Playbook, Four Products: What Building Dolfy, Dialable, Maximus, and Mimicall Taught Us

Most software agencies pitch prospective clients with case studies scrubbed of anything that might look like a mistake. AEGONTECH LLC has taken a different approach for the last two years: we build our own consumer and B2B products — Dolfy.ai, Dialable.world, the Maximus IPTV Player, Mimicall.app, and EmolyTicks — on the same engineering playbook we sell to clients, in parallel, with the same small team. That means every architectural decision we recommend to a CTO evaluating AEGONTECH as a development partner is one we've already made, shipped, and lived with the consequences of on our own infrastructure bill.

This is the story of what running four very different products at once actually taught us — not the sanitized version, the operational one: where a shared platform saved us months, where it cost us an outage, and where product-specific bespoke engineering was worth the extra maintenance burden.

Key Takeaways

• A shared internal platform (auth, CI/CD, observability, billing primitives) cut new-product time-to-first-deploy from roughly 8-10 weeks down to under 3 weeks across our last two product launches.
• Monorepo tooling reduced cross-product dependency drift, but it introduced a build-time tax that only became worth paying once we passed roughly 15,000 lines of shared code.
• Not every product should look the same under the hood — Maximus's real-time streaming workload and Dolfy's conversational AI workload have almost nothing in common at the infrastructure layer, and forcing them onto identical patterns would have been a mistake.
• Security baselines (OWASP-aligned reviews, dependency scanning, SOC 2-style access controls) need to be non-negotiable and centrally owned, even when individual product teams move fast and independently.
• The products that survived contact with real users were the ones where we treated technical debt — the extra rework created by choosing a quick fix over a better long-term approach — as a tracked, budgeted line item rather than an afterthought.

What Does It Actually Take to Run Four Products With One Small Team?

It takes a deliberate refusal to rebuild the same infrastructure four times. When AEGONTECH LLC started building Dolfy.ai alongside Dialable.world, the instinct was to give each product its own repository, its own deployment pipeline, and its own conventions — the classic per-team autonomy model. That lasted about one quarter before the maintenance cost became visible: four different CI/CD (continuous integration/continuous deployment — the automated pipeline that tests and ships code changes) configurations, four different logging formats, four different ways of rotating API keys.

The fix was a shared internal platform layer: a common authentication service, a common CI/CD pipeline built on GitHub Actions, a shared observability stack, and a common set of Terraform modules for provisioning AWS resources. Once that existed, spinning up Mimicall.app and later Maximus took under three weeks to first production deploy, down from the 8-10 weeks Dolfy and Dialable each took building their own foundations from scratch. That's roughly a 65-70% reduction in time-to-first-deploy for a new product line — the kind of number that matters directly to a founder trying to validate a market before runway runs out.

Monorepo vs Polyrepo: Which Structure Actually Scales Across a Multi-Product Portfolio?

Neither wins outright — the right answer depends on how much code your products genuinely share. We moved our shared platform code (auth, billing primitives, the design system) into a single monorepo (one repository holding multiple projects or packages, versus a polyrepo's one-repository-per-project split) once shared code crossed roughly 15,000 lines, because keeping five product repos in sync with a sixth "shared-lib" repo through manual version bumps was eating a full engineer-day per week in just dependency wrangling.

But we deliberately kept Maximus's video-streaming backend in its own repository. Its build times, its container base images, and its dependency graph are different enough from the rest of the portfolio that folding it into the monorepo would have slowed down every other team's CI runs for no shared benefit. This is the comparison we walk every client through: monorepo tooling (like Nx or Turborepo) buys you atomic cross-project changes and easier refactoring, but it only pays for itself once shared surface area is large enough — below that threshold, a polyrepo with clear versioned contracts is simply less operational overhead.

How Should Infrastructure Choices Differ When Every Product Has a Different Traffic Pattern?

They should differ a lot, and treating "infrastructure strategy" as a single company-wide decision is one of the more expensive mistakes we've watched other teams make. Dolfy.ai's conversational workloads are bursty and unpredictable — a serverless approach (running code in stateless, auto-scaling functions without managing servers directly, billed per invocation) on AWS Lambda fits that pattern well because idle capacity costs nothing between conversations. Maximus's IPTV streaming workload, by contrast, is sustained and predictable during peak viewing hours, which makes containerization (packaging an application with everything it needs to run consistently across environments, typically with Docker and orchestrated by Kubernetes) on always-on infrastructure the more cost-effective choice — serverless cold starts and per-invocation billing would have made Maximus meaningfully more expensive to run at its actual usage pattern.

"The infrastructure pattern that's cheapest for one product is frequently the most expensive one for another running in the exact same cloud account," is a lesson we now put in writing for every new client engagement, because it's the single most common mistake we see in technical due diligence reviews of acquisition targets and funding candidates.

We've also learned, sometimes the hard way, that database choice deserves the same product-by-product scrutiny. EmolyTicks' structured, relational data — user accounts, billing history, audit trails — lives in PostgreSQL, chosen for its strong consistency guarantees and mature tooling. Dialable.world's flexible, rapidly-evolving call-metadata schema lives in MongoDB instead, because enforcing a rigid relational schema during a period of fast product iteration was actively slowing the team down. Neither database is "better" in the abstract; the right choice depends entirely on how structured your data is and how often that structure needs to change.

What Security and Compliance Baseline Should Every Product Share, No Exceptions?

Every product, regardless of how fast its team is moving, gets the same non-negotiable security floor: OWASP-aligned code review checklists (OWASP being the Open Web Application Security Project, whose Top Ten list catalogs the most common and dangerous web vulnerabilities), automated dependency vulnerability scanning on every pull request, and SOC 2-style access controls — meaning least-privilege IAM roles, mandatory MFA, and centrally logged access to production systems. This is the one area where AEGONTECH LLC does not let individual product autonomy override company-wide policy, because a security incident on any one product damages trust in all of them.

"Security debt compounds faster than feature debt, because an attacker only needs to find the one corner you deprioritized," is the line we use internally to keep security reviews from sliding when a launch deadline is tight. In practice, this baseline has meant every product ships with the same request-rate limiting middleware, the same centralized secrets manager, and the same quarterly access-review cadence — implemented once in the shared platform layer rather than reinvented per product.

How Do You Decide When a Product Needs Genuinely Bespoke Engineering Instead of the Shared Playbook?

You look at where the product's core value proposition actually lives, and you protect that layer from standardization pressure. Mimicall.app's real-time call-quality algorithms and Maximus's video transcoding pipeline are the parts of those products that are actually hard to build well — that's where AEGONTECH LLC invests bespoke engineering time, custom performance tuning, and product-specific architecture decisions, because that's where the competitive differentiation lives. Everything around those cores — authentication, billing, deployment, monitoring — gets the shared platform treatment, because differentiating on "how logins work" creates maintenance cost with zero customer-facing benefit.

This is the same lens we apply when advising clients on custom development versus off-the-shelf software: buy or reuse the undifferentiated parts, build custom only where the product's actual value lives. Getting that boundary wrong in either direction — over-customizing commodity infrastructure, or under-investing in the genuinely hard technical problem — is where we've seen the most wasted engineering budget across dozens of client engagements and our own four products.

Frequently Asked Questions

Does running multiple products on shared infrastructure create a single point of failure? It can, if the shared layer isn't built with the same rigor as a standalone product. AEGONTECH LLC treats the shared platform itself as a product with its own uptime targets, on-call rotation, and testing requirements — not as glue code that gets less scrutiny than the products it supports.

How long before a multi-product shared platform pays for itself? In our experience, once you're launching a second or third product, the payoff shows up almost immediately in reduced time-to-first-deploy; the breakeven point for the upfront investment in building the shared layer itself typically lands within the first two product launches.

Is this approach only relevant to companies building multiple products, or does it apply to a single product with multiple services? The same principles apply to a single product decomposed into microservices (an architectural style where an application is built as a set of independently deployable services rather than one large monolith) — the question of what's shared platform versus what's bespoke differentiation shows up at the service level, not just the product level.

What's the first step for a company with one messy product trying to get to this state? Audit for technical debt honestly, budget time to pay it down incrementally rather than in one large rewrite, and separate your codebase into a clear "shared foundation" and "differentiated core" before adding a second product or service — retrofitting that split later is dramatically more expensive than designing for it early.

Bringing This to Your Own Engineering Roadmap

None of this required exotic technology — it required discipline about which decisions get made once, centrally, and which decisions get made independently, per product, based on actual workload characteristics. That discipline is exactly what AEGONTECH LLC brings to client engagements, whether we're doing technical due diligence ahead of an acquisition, architecting a new product from a blank slate, or untangling years of accumulated technical debt in an existing codebase.

If you're a CTO, VP of Engineering, or founder weighing in-house development against outsourcing, or trying to figure out why your own multi-product roadmap keeps stalling on infrastructure decisions instead of shipping features, we'd welcome the conversation. Reach out through AEGONTECH LLC to talk through a free consultation on where a shared platform layer — or the deliberate decision not to build one yet — fits your situation.