OtherShut Down

101 Studios

101 Studios built an educational game for classroom use, but professor interest did not become adoption because each class wanted a different customized version.

View original story

Product snapshot

What it was

101 Studios produced an educational game where gameplay encounters acted like learning prompts for medical topics.

Who it was for

professorsstudentsclasses using educational games

Problem / value

It tried to turn difficult memorization into more engaging game-based practice.

Core workflow

A professor would adopt the game for a class, students would play it, and the content would reinforce course material.

Core dependency

Classroom adoption depended on professor relationships, course timing, and course-specific content needs.

Product form

educational video gamePC democlassroom learning game concept

Pricing model

The source mentions a monthly subscription idea and a class-adoption model, but exact price and revenue are not disclosed.

Competitors or alternatives

traditional coursewarelearning management systemscustom classroom activitieseducational games

What happened

Summary

101 Studios built an edutainment game before proving that professors would adopt it in real classes without heavy customization.

Outcome

The startup never reached product-market fit and the work shifted into a different game project.

Core risk

Indirect buyer interest can hide implementation friction until after too much product work is already sunk.

Shutdown reason

The classroom sales and customization path was too hard to scale after professors did not commit to implementation.

Demand signal

The idea sounded appealing to professors, but the source says many wanted X, Y, and Z before using it or liked the concept but not for their class. That means interest did not prove a real classroom workflow, buyer, or repeat purchase path.

Distribution issue

The model depended on relationships with professors and class-by-class adoption. That made distribution slower than a simple consumer launch, because every sale also required implementation fit, customization, and timing around courses.

Timeline

  • Started with an edutainment game concept inspired by game-based memorization
  • Built a small demo level with custom assets and a custom game engine
  • Spent about three months building and about three months networking
  • Pitched professors through a business-to-professor model
  • Found that professors liked the concept but did not adopt it without course-specific customization
  • Pivoted away after failed sales pitches

Before you build

Why it matters

Education, enterprise, and workflow products often fail between “great idea” and actual implementation. That gap must be tested before a large build.

Primary check

Validate the adoption workflow, customization burden, and budget owner before building education software around classroom enthusiasm.

Checklist

  • Will a real class use it this semester?
  • Can the same version serve more than one class?
  • Who has authority and budget to require adoption?
  • Get one professor to commit to a dated pilot before expanding content
  • Define who pays: department, professor, student, or institution
  • Prove one reusable course template before promising custom versions

Relevant if

  • You are selling through teachers, managers, departments, or other indirect buyers
  • Your product needs workflow change from people who did not buy it themselves
  • Your MVP requires custom content for each account

Less relevant if

  • You already have a signed pilot with a fixed implementation date
  • The product can be used directly by the paying customer without classroom or team rollout

Pre-build tests

  • Run a no-code classroom pilot with existing tools and a single lesson
  • Sell a paid pilot before building custom game content
  • Interview professors about implementation blockers, not just whether the concept is interesting

Transferable lessons

  • Validate adoption workflow before building custom content
  • Separate concept approval from purchase and implementation commitment
  • Avoid a prototype that only works after bespoke customization

If you build this today

A better version would start with one narrow course, one professor willing to run a pilot, and a non-custom MVP that proves students use it before building more game content or a custom engine.