So this is my first scheduled build in public blog post. My aim here is to explain what I did in the last week and what I plan on doing for the next week.
Last Week
So marketing tasks I did last week were:
- Wrote a blog post about getting fired
- Wrote a blog post about building SpyGather.com
- Participated in conversations about SaaS bootstraps/starter kits on Indie Hacker and Reddit
- Sent a newsletter
Parthenon development related tasks:
- I did a quality assurance run through on the skeleton app.
- I fixed a bunch of stuff
- I worked on a notification centre system that will allow people to define how they get notifications/alerts within an application.
- I released version 1.1.1 - Changelog here
- I updated and improved the documentation
And the general tasks:
- Deployed a basic site on humblyarrogant.io
- Improved the Spygather.com landing page.
- Redirected old blogs to getparthenon.com
What went wrong
After testing the buy Parthenon flow by hand multiple times. Turns out I broke the flow by changing the security access roles at some point. So for a few days people probably have been trying to take advantage of my 50% lifetime voucher IGOTFIRED and haven't been able to. So I've extended the voucher until the 7th of May.
Next Week
So my major plan for next week is to carry on with the development of the notification centre. It's a common problem that I've had in multiple apps and I'll have in an internal app I want. Reflecting back on last week, my issue was that I didn't break down the features correctly. For the most part I just had one issue, "Create notification Centre", which is obviously not good. In reality, what I got done was I built the add email notification channel and send notifications.
QA - Quality Assurance
One of the things I want to do for Parthenon is to have an extremely solid QA setup. I want people to be able to rely on Parthenon and therefore QA is important.
Currently, there are lots of automated tests for Parthenon. These are run constantly. Below is a diagram of the test plan. I work on a core repository and when the tests pass within the core repository, then the bootstrap and funded bundles are created; these both have tests; once these pass then there are applications that are triggered and tests run for each application. One of the benefits of this approach is that I'm able to find breaking changes since a test will break and I'll know to fix the breaking change.
But the issue is that for me to test things by hand it becomes harder. Why? Because during the development of the Parthenon, I often wrote the tests for a Parthenon feature in one of the applications I built to develop the Parthenon. Some features are only used in one of these applications. Figuring out which application can be a pain.
So moving forward, I'm going to create a QA application. This is an application that will implement every functionality and support every provider. It'll have automated tests, but more importantly, it'll be one place I'll be able to go to test features by hand. See emails being sent via MailGun, Sendgrid, Postmark, etc, with just clicking buttons instead of having to change configurations or using a specific application.
This is obviously a long term plan, but I feel like having a rock-solid QA process as soon as possible will help me in the long term and help Parthenon customers too!
Call To Action
I read somewhere that every blog post should have a call to action. So here is a shameless call to action. Get Parthenon now using a 50% off lifetime voucher IGOTFIRED (story here). The voucher expires on the 7th of May, it'll never be so cheap again. So if you're still at the thinking and planning stage, it may be worth your time locking in this sweet price. Buy now!