Building Within Constraints: Lessons from a Two-Week Project
How a two-week deadline forced every engineering decision, and why scoping, MVP design, and choosing what not to build mattered more than building the most flexible system.
As engineers, it's easy to become attached to building the perfect system. We want reusable architectures, polished interfaces, flexible pipelines, and systems that can handle future requirements. Those are all worthwhile goals, but they are not always the right goals for the project in front of us.
Holo Dance Studio reminded me that every technical decision exists within a set of constraints. In this case, the biggest constraint was time. I had two weeks to build and release a complete product, and every engineering decision had to support that goal.
Starting With a Realistic Goal
Holo Dance Studio began as a personal project during a holiday break. I challenged myself to build and ship a complete application in two weeks.
Before development started, there were plenty of ideas that would have made the application more capable over the long term. Supporting multiple characters, richer environments, a generalized rigging workflow, and a more extensible interface all sounded worthwhile. None of them, however, were necessary for the first release.
Working alone also meant every responsibility belonged to me.
- Engineering
- Character creation and rigging
- Asset production
- UI implementation
- Publishing
- Marketing
- Documentation
- Distribution
Every feature I added competed with the time needed to finish one of those responsibilities.
At that point, the question changed.
Instead of asking how good the application could become, I started asking what I could realistically finish within two weeks.
That simple shift made every later decision much easier.
Defining the MVP
The first version of Holo Dance Studio only needed to accomplish four things.
- A rigged 2D character
- A dance animation editor inspired by Halfne Miku Studio
- Green-screen background support for external video editing
- A Windows release supporting both English and Japanese users through a language-light interface
Everything else could wait.
Defining that scope before building the supporting systems gave the project a clear finish line. It also made feature discussions much simpler. If a feature didn't help achieve those four objectives, it wasn't part of the first release.
Choosing What Not to Build
Building an MVP is usually described as deciding what to build.
In practice, I found the opposite to be true.
Most of the work was deciding what not to build.
Character swapping is a good example.
On paper it sounds like a relatively small feature. In reality, it affects the rigging workflow, the content pipeline, the user interface, testing, and future asset creation. Those investments make sense if the project is expected to grow over a long period of time.
For a two-week solo project, they didn't.
The same reasoning applied to richer environments and more generalized systems. They were good ideas, but implementing them would have delayed features users would actually interact with during the first release.
Rather than solving problems I might have in the future, I focused on solving the problems required to ship the product in front of me.
Planning the Work
Keeping the scope small was only part of the solution.
I also divided development into production phases so I always knew what needed attention next.
- Character creation and rigging
- Asset pipeline
- Animation systems
- User interface
- Persistence
- Platform support
- Publishing
Working through one phase at a time reduced context switching and made progress easy to measure. It also prevented multiple unfinished systems from growing at the same time.
Looking back, this planning was just as important as the technical decisions themselves.
Expanding the Project
Once the original prototype was complete, I revisited the ideas I had postponed.
Because the MVP already worked, every additional feature became optional. I could evaluate each one based on the value it would add rather than feeling pressure to finish everything I had imagined at the beginning.
That shift also changed how I approached product decisions. During the initial two weeks, every engineering hour was spent getting the application to a complete, shippable state. Once that milestone was reached, I could look at the project through the lens of product ownership instead of implementation.
Instead of asking, "Can I build this?", I started asking, "Will this make the product meaningfully better for users?"
That led to several significant additions.
- A cross-platform save system supporting Windows and Android
- ARCore integration that expanded the application into an augmented reality experience
- A portable save format allowing performances to move between platforms
- Publishing materials, promotional assets, and public documentation
None of those features were required to prove the original idea.
They became worthwhile because the foundation was already complete.
Looking Back
If I had more time or additional engineers, I would have approached some systems differently.
Supporting multiple characters and investing in a generalized rigging workflow would have been worthwhile for a longer-lived product with ongoing content production.
For this project, those systems would have increased development time without helping me reach my original goal.
(A bit about who's writing this: 10+ years shipping commercial titles on PC, Switch, and mobile →)
Generalizing a system only pays off if the project has enough time left to benefit from that flexibility.
Generalizing a system only pays off if the project has enough time left to benefit from that flexibility.
Lessons I Took Away
Looking back, this project influenced how I approach engineering far beyond solo development.
- Constraints should shape the architecture from the beginning instead of being treated as obstacles to work around.
- A focused MVP creates more opportunities than an ambitious first release that never ships.
- Breaking work into clear production phases keeps progress measurable and reduces unnecessary context switching.
- Additional flexibility should be earned. Generalizing systems too early often creates more work than value.
- Shipping a working product changes future engineering discussions into product discussions. Once the foundation exists, new features can be evaluated based on the value they deliver instead of the excitement of building them.
I still use these ideas today when estimating work, discussing scope with designers and producers, and deciding where engineering effort will have the greatest return.
Final Thoughts
The biggest lesson I took from Holo Dance Studio wasn't about Unity or augmented reality.
It was about choosing where to spend engineering effort.
Every project has limited time, limited people, and limited opportunities to invest in new systems. Building everything we can imagine is rarely the right answer.
Finishing the MVP gave me something I didn't have at the start of the project: options.
From that point forward, every new feature was a conscious investment instead of an unfinished obligation. Looking back, that decision had a bigger impact on the project's success than any individual system I built.
What's Next?
Curious what this looks like on a shipped, team-based title?
👉 See the Forestrike and Puzzle Panic case studies
Based in Japan • Available for technical gameplay implementation and cross-disciplinary development.