I wanted to give an update on the first real app I built after the event modeling and event sourcing workshop in February (https://www.linkedin.com/pulse/another-weekend-event-model-jocelyn-mae-englund-zvgef/)
Since then, I’ve been building and maintaining more and more little apps as part of my learning journey. (You can find most of them here:https://itsybit.se/projects/)
I did manage to finish my MVP and have the kids try it out in March, with the basic functionality:
- create a new household
- invite members
- add chores
- log chores
I’d even managed to add some non-essential features like setting status messages with SignalR, activity feeds, etc., just to make the app interesting enough for my kids to actually use.
Spoiler: app usage was fun initially, but it didn’t really stick. So in March, my husband also vibe coded an integration into the ChoreMonkey API, building a TV display for the same information, and we’ve made it a home screen on our TV. He added other things like calendar and weather integration that change the theme of the display too. It still seems to work! Although the TV has rarely been idle in this household, hopefully that will change now that it’s warm outside.
While my husband was doing the carrot approach, I was doing the stick. Since March was going to be the first full month of ‘production use’, I decided to build a salary module where I could assign values to certain required chores that would cause deductions when not done. Don’t worry, there are also bonus chores they can do to make up for the ones they missed.
The whole point of the app was for me to know how much to deduct from their allowances for missed chores, but I was able to ‘ship to production’ without the main functionality, all because the system was event sourced.
Anyway, by the 25th the functionality was completed and the kids were able to see the projection of their allowances, as well as the chores they had missed. (This is me preparing my kids for the harsh reality of adulting…)
Of course, I didn’t stop there. To make it even more real world, I then added payslip generation so they could see historically how much they had earned, since the app display had only shown information for the current month. You can see that March was not at all a good month for chores.
I’m happy to report that they did a much better job the next month!
What I’ve learned from the project
I learned a lot building this app with the help of AI. In terms of process, I think having the foundation and architecture the way it is was key to being able to just keep iterating. I’ll admit I didn’t really build event models after the first MVP, but I did spend the time to do that part properly, designing the initial event model and making sure the vertical slices were organized properly, both backend and frontend. I made sure I had a proper deployment pipeline in place so every change can go into production at a push to the repository. I made end-to-end tests for the key features to make sure they don’t break as I add new ones.
It’s funny now that I think about it, the reality of MVPs and POCs today is that people seem to build ‘throwaway code’ because they THINK it will never hit production. We all know how that ends.
The salary module is actually a good example of why the foundation paid off. The whole point of the app was to track deductions, and I shipped to production without it. If the system hadn’t been event sourced, I would’ve been stuck waiting on the main feature before anything could go live. Instead the events were already being captured from day one, and when I built the projection a few weeks later, the history was just… there.
I think the common assumption is that MVPs should cut corners so you can move fast. What I found is kind of the opposite, the corners I didn’t cut are exactly what let me move fast later. The agent could only iterate quickly because there was a structure to iterate within. Skip the event model, skip the slices, skip the pipeline, skip the tests, and every new prompt is building on sand.
being in tech 