Ideas & Writing Michael Orlando

If you want the venture index page, start here: IDC Projects.

IDC Projects is the name I used for the mobile app and game studio that grew out of my first venture, the Interdisciplinary Design Collaborative (IDC), at Missouri S&T.

Between roughly 2008 and 2015 (especially 2011–2014), we shipped a portfolio of 25+ titles across iOS, Android, Amazon, and Windows. One of those titles — Memory Matches — became a long-running franchise and, over time, a $1M+ property.

This post is the public narrative version of that story: what we built, how we operated, what the studio taught me, and why this chapter still matters in the larger arc that later became Lumate.

What IDC Projects actually was

IDC Projects was a student-powered studio with a very specific thesis:

  • ship real products (not demos)
  • instrument everything
  • treat distribution + monetization as first-class design constraints
  • use the studio as a training ground where students could graduate with shipped titles and real operating responsibility

At the time, the App Store economy was still young. If you could ship consistently and iterate quickly, a small team could compete globally.

Our early experiments included:

  • BarcodeScan, one of our first utility-style iPhone apps
  • Memory Matches, a simple card-matching game that turned into a franchise

Those early launches validated something important: if we built a repeatable engine for shipping and learning, the portfolio could become self-funding.

Memory Matches (the flagship)

Memory Matches started simple: a clean take on the classic concentration game, built for mobile. Then it got iterated for years.

It became the anchor for the studio because it produced “real” outcomes:

  • meaningful App Store chart performance (including top placements in the US store)
  • 1.5M+ downloads
  • 100M+ ad impressions
  • $1M+ in revenue across ads and in-app purchases

The bigger point isn’t the exact numbers. The bigger point is what those numbers made possible: the game wasn’t just a product — it was an operating substrate. It funded more experiments and created a live environment where we could test acquisition, retention, monetization, and ad performance at scale.

The operating model (why we could ship so much)

IDC Projects was never “just” a game studio. It was an operating system for high-output product work with low fixed cost.

A few design choices mattered a lot:

1) Portfolio thinking instead of single-product thinking

We treated the studio like a portfolio: many small titles, a few bigger bets, and continuous shipping. The goal wasn’t perfection — it was throughput with learning.

2) Data-driven iteration was the default

We built with an analytics-first mentality. That meant:

  • instrumenting engagement and monetization flows
  • using performance data to decide what to improve (and what to stop doing)
  • designing releases as experiments instead of “final” launches

3) We built infrastructure, not just apps

As the portfolio grew, we built internal systems to make shipping cheaper and faster:

  • shared code frameworks
  • repeatable release and QA patterns across multiple app stores
  • monetization tooling

One of the most important “behind the scenes” systems was our ad mediation and yield-optimization work. Improving eCPM by 35–50% changes what a portfolio can fund.

4) Profit-sharing made the student talent engine real

More than 20 Missouri S&T students cycled through the studio in roles like engineering, art, design, QA, product, and marketing.

The profit-sharing / upside model mattered because it aligned incentives with shipped outcomes. People weren’t “helping on a student project.” They were participating in a real portfolio with real feedback loops.

Marketing, distribution, and partnerships

We learned quickly that shipping is only half the job. Distribution is the other half — and it is often the harder half.

One of the most vivid examples was burst-campaign work (including a W3i partnership) that helped us hit chart performance and install velocity spikes (including days around 70K installs/day during campaigns).

We also operated across platform cycles that mattered historically, including being a Windows 8 launch partner during that ecosystem push.

How this turned into Lumate (and why IDC Projects still matters)

IDC Projects is where I learned something that later became the Lumate thesis:

ad performance changes materially when inventory has better contextual and audience information

The studio’s mobile portfolio wasn’t only a revenue engine. It was a laboratory. The data, the monetization infrastructure, and the market exposure were what made it possible to see the shape of the larger opportunity — which ultimately became Lumate and AdTrade.

If you want the high-level narrative across the whole arc (IDC → IDC Projects → Lumate), start with: The Lumate Arc.

If you want to work with me on this chapter now

There are a few ways this chapter shows up in the present:

  • Portfolio re-commercialization: modernizing older titles, updating tech stacks, and re-testing distribution
  • IP and brand leverage: treating a franchise like Memory Matches as a long-lived digital asset, not a one-time launch
  • ad monetization systems: improving yield, mediation, analytics, and experimentation loops across a product set

If you’re reaching out about any of those, the best first message includes:

  • what asset(s) you care about
  • what outcome you want (relaunch, revenue, learnings, acquisition, partnership)
  • the constraints (timeline, budget, platforms, and what’s already built)