Problem
Build an app that makes a physical pixel art product feel like a real creative platform, not just a companion utility.
Approach
I work across the Flutter product surface and the supporting Supabase backend: a custom pixel-art drawing engine, community and moderation features, offline-safe local storage, cloud sync, and database-level access control where product rules need to hold beyond the UI.
Outcomes
- Live on the App Store and Play Store.
- 1,100+ registered users and 1,600+ prints created as of November 2026.
- About 540 starter kits sold as of November 2026.
- Four App Store releases between August and October 2026.
- The test suite grew from about 600 to 3,000+ tests between April and November 2026.
inkBlox is the strongest example of the kind of work I want to keep doing: real product constraints, real users, and technical decisions that directly affect the experience.
The app lets users create pixel art on a grid canvas and share their work to a community feed. That sounds straightforward until the editor starts needing product-quality behaviour: responsive drawing tools, usable undo/redo, mirror mode, selective rebuild performance, offline safety, and moderator permissions and block rules enforced in the database.
On the product side, this has meant shipping and refining the actual user experience. On the technical side, it has meant building a custom drawing engine with an intent-based input pipeline, keeping state immutable, and using a Supabase setup that goes beyond basic CRUD. Moderator permissions and block rules are enforced in the database with RLS and triggers, and SQL migrations go to staging first.
It is also a good example of the overlap between frontend and backend work that I enjoy most. A drawing app lives or dies on interaction quality, but product reliability comes from the less visible parts too: local persistence, sync behaviour, schema design, and careful data access rules.
Because inkBlox is closed-source, I treat it as a case study in product and architecture decisions rather than a public code sample. That is still useful context for the kind of freelance and product work I am aiming for: shipping user-facing software while staying comfortable with the systems behind it.
Screens
