Category Archives: Bootstrapping

Gearing up for product development

I decided to take a break from the growing an email list course. I have been mulling over some of the issues I had at the end of the Week of Hustle. I think that there is room to improve the concept and make it into a more robust product development framework after you are done.

Let’s review

Blogging and social accountability has been a strong point of the system so I think that should stay. It’s also a good way to share information on how you shape the product and keep things transparent. The issue was really in the planning stage. I had written a roadmap as instructed, but It hadn’t crossed my mind that there would be a design piece at all. That’s because I hadn’t really thought about all the tasks needed for something like “You sign up for an account.”. That sentence doesn’t really reflect all that you needed to do.

So let’s say you want to develop your own software product, what can you do to help with the process? It can be pretty overwhelming as a first timer and you might get bogged down in needless details as well. I still do. All. The. Time. It’s frustrating because you feel like you’re never making progress or not enough.

What are others doing?

Here are two methods I have come across over the past year that I found useful.

Amy Hoy’s doing things backwards

First thing you should do is think of the product in its final state and think of what you need to achieve that. Not in small detail, but in broad strokes. This idea comes from Amy Hoy‘s 30×500 class where she talks about working through a goal backwards starting from the desired goal. She has a great example in her free guide using Frankenstein.

Creating Life

When I first read the guide, I thought that was a very useful mental exercise. I didn’t think about it at the time, but I feel my roadmap actually used that concept pretty well. Needless to say, sometimes we do this naturally, but other times we just drive forward without thinking. You should always try to keep it in mind.

If you follow the guide, she suggest continuing to divide tasks into smaller and smaller pieces. I tried doing that a few months ago and I just thought the result was really overwhelming. You would work your way back after and it was hard to pick which small bit to work on or prioritize.

How Ryan Singer manages products

This bring me to a second useful method. Yesterday, someone posted this video by Ryan Singer on twitter and it wasn’t something quite new to me since he had written a post about it in the past. I just hadn’t thought about it in a while and, even more important, I hadn’t thought about it in the context of Amy’s guide. But I have been looking for a system to help me build Helthe. So I could stay focused and productive.

So to go back to the video, Ryan talks about individual vertically integrated scopes of work… Say what!? All it means that you shouldn’t be dividing your work per role (programming, design, etc.) as we often do, but to think about everything in terms of scopes of work. Scopes could be something sexy like a feature or something less sexy like authentication. I put a screenshot from the video to help illustrate the idea.

Screen Shot 2013-11-20 at 11.55.21 PM

The other important element of the scopes is that they are generally very self-contained. You might have a dependency (like registration depends partially on payment in his example), but what is really nice is that once you have done all the tasks for a scope. It is really done. You don’t have to go back to it. Which is what was missing from Amy’s guide.

Deciding which scope to use is based on learning opportunity. Which scope will force me to ask the most questions about my problem domain and allow me to learn the most about it. As a programmer, we tend to gravitate towards what is the most fun to code or the easiest.

A formal attempt

So let’s try to formalize a system we could use. I would also say that it is probably useful to blog about all of this. Social accountability is a strong motivator. That’s my plan at the very least. I’ll go through my proposed steps using Helthe as an example.

First, I would work backwards from my desired outcome and develop a high level map of what I want to build. Ask yourself what do you need? So Helthe is an application error monitoring service for PHP. What do I need to go in Beta? I came up with this map. You might notice that I don’t have marketing site there. Not sure if it should be or not. It’s not part of the product per say and it’s not something I would want to tackle until I understood your problem domain completely.

Initial Helthe Scope Map

Second, I would find the scope of work that offers the largest learning opportunity. Honestly, I didn’t find this step easy at all. Initially, I thought maybe the dashboard or the project itself, but Helthe is about errors so I decided that the whole error management system (grouping, displaying, etc.) really forces me to ask some tough questions about the domain.

Third, I’d divide your scopes into tasks. They should include everything you need to check off that scope as completed. You can do it without a process, but I would go at it backwards the same way you came up with the map. If you come up with a lot of tasks then it might mean that you need to divide things further at the high level.

Should you do it for every scope right away? I am not sure. It seems to go against the idea that if you are going from the largest learning opportunity, it might impact the task lists for the other scopes as you answer questions about your problem domain. You could probably start with an initial list though.

I purposely left my task list out because I didn’t have time to think it through completely. I also I feel it deserves to be a post by itself (probably my next one). Each scope should be its own post.

All that is left is for you to go through each scope one by one. You’d pick the next scope by continuously asking yourself which one offers the largest learning opportunity.

I’ll be exploring this further

If you’ve liked what I have been writing and want to hear more, you can subscribe to my mailing list here! I have been writing a lot so I am still figuring out how to approach things for the list. You can also keep checking the blog every day if that’s your thing!

A week later

A week ago, I was writing a post about getting back into the habit of things with building Helthe. I was leveraging my increased motivation since I got sick in October to participate in the Week of Hustle that was organized by Justin Jackson for our group JFDI. The goal was for us to get a small product built-in a week or finish something concrete on a product you had been working on. I chose the later.

How did I do on the roadmap

On that same day, I also posted a roadmap with what I was planning to do during the week. I thought it might be useful to review it and share my thoughts on it.

1. You sign up for an account.

I completed the sign up page and login page on the first day and that was great, but my fears ended up justified. I did not end up spending time on the design aspect of things and because of that I cannot show the work I did.

2. You can create a project with its own API key.

I had code ready for this already, but I made sure thing worked so this part was easy, but very necessary.

3. You get a PHP library (on GitHub) that you can add to your project for tracking application errors.

This probably should have been split in two since there was also the API code to fix, but I got it all done in the same day. Helthe now has a basic library up on Github which can be used by early adopters as I get all the integrations up and running.

4. Errors get sent back to Helthe and it determines if it is a new error or an existing error.

This was also an important feature to get to work. You don’t want users to get spammed with every error otherwise you are not better than a hacked solution. So I have all the errors grouped up by message currently. I plan on having something more elaborate in the future.

5. You receive an email whenever a new error is created.

I ended up spending two days on this when I expected to spend maybe a couple of hours. As I explained, I ran into problems left and right. From setting up Mandrill to getting emails to display properly, I never got a real break to get this done reasonably quickly. I did end up getting it done though and it looked  great!

6. Update my marketing site to reflect that we entered a stage where you can test.

There is a new small update in the FAQ about being passed my november 4th launch date, but that’s all I could get up without a design pass on the actual front end.

7. Refine my marketing message following a campfire talk with Andy Parkinson.

I am very happy with the changes to the marketing site in respect to this. I did a big blog post about it last night with the resulting text change.

Design should have been on the roadmap

This is a big one I think. I wish there was more to show on the Helthe website if I had planned for it. I didn’t really think of it at the time though. I figured I could do both, but, as I discovered doing the email design, it can be very time-consuming to do simple things even with frameworks.

Blogging has been a big winner

I managed to blog for 6 out of the 8 days and I have to say that felt great. Writing was easier because I was writing about what I was doing, but in the larger scheme of things it didn’t really affect viewership at all. That was expected because I wasn’t really writing to help readers, but for myself about myself (me! me! me!). It should be about them and not be.

That said, I do find that it was useful for rebuilding the habit, but it is still very time-consuming for me. I wonder if I will be able to be as prolific as I move towards writing useful content for readers or able to maintain the habit.

Overall this was a success

I feel very good about how the week turned out. I work very well when I feel accountable to someone, but it’s hard feeling accountable to anyone when you work alone with no clients. This helped tremendously.

With this, I am closer to having something to sell, but, while I worked and got stuff done, I am definitely not closer to getting the marketing piece working (like getting people to my site,etc). This can be discouraging, but there are so many pieces to this that I am glad I got some sorted out. Marketing is always a challenge when you have nothing much to leverage.

What’s next?

I have to figure out how I can turn this into a framework I can work with continuously. I hope to come back in a day or two with some ideas. Till then, you can keep checking up here or you can subscribe to my mailing list.

An email adventure

The past two days I have been knee-deep in email! Yesterday, I started by writing some basic documentation for Helthe Monitor which was on my to-do after my previous post.

Hooking up Mandrill

As I mentioned in the roadmap, Mandrill is the transactional email service that I chose for this project. I did extensive research on all the providers (Sendgrid, Postmark, Mailgun, etc.) when I was working on the previous Helthe version. I chose them due to their excellent pricing overall and their free tier. On top of that, they’re a spin-off company of Mailchimp which has excellent knowledge of email infrastructure.

So having done this before, I figured this was going to be quite easy  to do. The coding part didn’t take very long since I had done it before, but Symfony wasn’t sending the emails to Mandrill. Symfony would say that the email was sent, but it never made it to Mandrill. The rest of the day was spent troubleshooting the issue unsuccessfully.

I ended up solving the issue today by using SSL for the SMTP, but I never quite figured out why it did not work unencrypted. Once that was done, I made sure emails were only sent for new errors and not every time an error is logged.

Holy email styling batman!

For the rest of the day, I decided to tackle styling my emails. As I said Monday, I wasn’t sure I would have time for it, but I decided to work on the emails today. I had never done email styling before, but, armed with this sweet post from, I thought I could get it to work quickly. It seemed that way at first. My first version looked great. You can see an example below.

But then I saw it in Gmail. It looked horrid (I didn’t put some robot email skull monster screenshot for nothing!). None of the stylings were showing and I didn’t know why. I looked up some stack overflow questions, but nothing useful came out of it. I decided to try out a white color scheme and things looked better in Gmail, but I wanted black dammit!

Screen Shot 2013-11-14 at 10.26.35 PM

Eventually, I mentioned my problems in the JFDI campfire chat room and Justin pointed me towards this great tool from Mailchimp (!!!) called the Automatic CSS Inliner Tool which converted all the styles into inline ones BECAUSE APPARENTLY IT MATTERS. I love you email, but as if having to use tables wasn’t insulting enough already.

As a final note, I plan on using the first one, but if you like second one more. Let me know!

2 days left

We’re down to two days left now. I did a pretty good dent on that roadmap already. I think the main goal is to fix up the marketing site as was originally planned. It’s outdated so I would like to update it. Fix up some of the copywriting to reflect some discussions I have had the past week.

If I have time, I will do more design work on the frontend of the application so that I can put some sweet sweet screenshots! Nothing says progress like screenshots!

Keep up with my progress

I have been bad and haven’t sent emails everyday as I should, but I’ll be sending updates (I swear!) by the end of the project to my mailing list. You can subscribe here and you will get all the info when things are ready for testing.


Very productive day today. I have done a good dent in the roadmap. I didn’t get to write the essays I wanted to do. I should have time to tackle that tomorrow.

Working API

As I mentioned yesterday, my API code was full a bit of mess as I was working on building a custom Symfony Firewall for authenticating a user using an API key (either as a query or HTTP header). I had worked on having it decoupled so I could open-source the bundle for it eventually.

So all that was cleaned up and committed today. I then proceeded to fix my code so errors would be grouped together when multiple ones are submitted. Following that I got all errors submitted assigned to a project using the projects API key.

Helthe Monitor

As I was fixing my API code, I was also working on Monitor, the basic PHP library for Helthe. I got the initial commit up on Github. At the moment, it is a simple wrapper around Guzzle, a PHP library to build HTTP clients. A very useful library if you are looking to work with or build a service with HTTP requests. I still need to write the documentation which I neglected to do, but I plan on doing it tomorrow.

So things are moving along quite well, a lot of elements of the roadmap are far ahead. I don’t have a sexy  UI shot to show yet, but below is a database screenshot showing test errors.

Screen Shot 2013-11-12 at 11.27.56 PM

Keep up with my progress

As always, I’ll be sending updates of what is going on with the project to my mailing list. You can subscribe here!

That first commit

My first day is drawing to a close and I have committed a working signup page and login page. It’s not a bad outcome, but I feel I should be even further ahead.

Still fighting my enemy

I had a lot of code cleanup to do because I was in the middle of converting my code to be more DDD-friendly and SOLID before this started. This kind of premature optimization always ends up bogging me down.

It’s always a real challenge to balance learning how to do new things and being productive.

Tomorrow I plan on tackling the Helthe API code that is also in its own transitionary phase and get it in working order. I have a couple of small essays I would like to publish as well. We’ll see how all this goes!

Design worries

I don’t have a screenshot to share today because I am just using auto-generated HTML directly. It’s functional, but that’s it. I might try to take a look at making things prettier tomorrow as well if I finish early (ha!).

It dawns on me I should have probably put a line item for design. I am not a designer. I did a great job in a short time for my current marketing site, but I think this might end up being pretty time-consuming overall. I will probably just scramble to dress everything up and do a proper design pass after the week is over.

Keep up with my progress

As always, I’ll be sending updates of what is going on with the project to my mailing list. You can subscribe here!


I am spending my first day trying to stabilize my code since I was working on a few things before the Week of Hustle started. Our goal for today was to submit a roadmap to plan for the next few days.

What’s coming ahead

Here is the plan for the next week:

  1. You sign up for an account.
  2. You can create a project with its own API key.
  3. You get a PHP library (on GitHub) that you can add to your project for tracking application errors.
  4. Errors get sent back to Helthe and it determines if it is a new error or an existing error.
  5. You receive an email whenever a new error is created.
  6. Update my marketing site to reflect that we entered a stage where you can test.
  7. Refine my marketing message following a campfire talk with Andy Parkinson.

Technology Stack

For people wondering about what I have been using to build Helthe. Here is the list:

Symfony feels a bit limiting for pumping out something quickly like this, but I am not planning on changing. This is only a first step and Helthe is a service that will be maintained for years.

Keep up with my progress

I’ll be sending daily updates of what is going on with the project to my mailing list. You can subscribe here !

Getting back into it

It’s been a month and a half since my last blog post. Personal illness got in the way of things for most of October and I have been slowly getting back into it over the past week. My pre-order deadline for Helthe has come and gone and I have gone back to working on the project daily. Now, I am building back my blogging habit.

Welcome to the hustle

Just before getting sick, I joined  a community of bootstrappers called JFDI which is pretty great for people working alone in their basement like myself. We’re running an experiment this week called Week of Hustle where a group of us will try to build a small product in a week. You can also use this to finish a project that you have been stagnating on. That’s what I’ll be doing.

I had to answer some preliminary questions yesterday which I want to share.

  • What is your personal goal? Get Helthe into user testable stages and accepting early adopters.
  • Who is your audience? PHP Developers (like myself) who care about application errors and their impact on clients.
  • What pain are you trying to solve? In PHP, it’s really hard to find errors when things are not working. Often, you just get a white screen. If I can save developers 1 hour of debugging a month, the product pays itself.

While things have been very good this past week, being sick and not working for a month is a pretty daunting hurdle to get over. This will get me back into the flow of things even more and help me get me over my #1 enemy.

Code is my enemy

The weakness is your love of creation. You love to write clean, tested, scalable, extensible, beautiful code.

Jason Cohen

I love coding. I think myself a craftsman more than anything else and I want to be proud of what I built. This is great, but it also causes some serious problem. I am not shipping in a timely manner. This is exacerbated by working alone and setting your own rules and timelines.

So because I have a limited timeframe, I will be forced to limit my scope heavily. I will have daily goals to meet and be accountable for to help me focus and not get sidetracked.

This isn’t a new weakness or something I have just come aware of. I would say I have struggled with it since I started a year and a half ago, but it’s one I keep working on (like my blogging habit).

Speaking of blogging habit

I’ll be blogging everyday during this. Shorter posts (like this one) and maybe multiple times a day about various Helthe topics (roadmap, ideal customer, design, etc) relevant to the work I am doing this week. So stay tuned!

Want to follow my progress? I’ll be sending daily updates of what is going on with the project to my mailing list. You can subscribe here !

The one tool I wish I had in PHP

One thing you realize when you work by yourself is that you get a lot of benefits from tools that can automate some of your work or save you time. I have grown quite familiar with tools that you want around you when developing great PHP applications. With your production servers, you want services and products that can help you with:

  • Server monitoring
  • Server provisioning
  • Log management
  • Checking for uptime
  • Application performance
  • Application errors

This doesn’t even include developer specific services like continuous integration.

Those production server errors

Here is a common scenario.

Our client just called saying they had an error in production.

I can’t count the number of times I heard that quote. Production server errors in PHP (often the white screen of death) have always been a huge problem. When you get production errors in PHP, it’s a very painful experience for a lot of reasons.

Often, you weren’t aware of them so you have to go comb through your logs to see if you can find anything useful if you have log management that step is easier. If you’re a bit more on top of it, you get an email with a stack trace. But after, you have to go through this awkward reverse engineering process where you’re missing a lot of key information. How do you get that information?

For a lot of PHP devs (especially in the WordPress world), you will doing var dumps directly in production. That’s cowboy coding and that’s bad! Often, it’s necessary because you just don’t know what’s going on. Log information and a stack trace is sparse at best.

Meanwhile on the web…

I asked the Montréal WordPress Facebook Group what they used for errors, but only one person used an error monitoring service (Airbrake). I am always checking what the other big web languages (mainly Ruby and Python) are using to solve their problems and there are a lot of general tools that were built for this (e.g. Raygun and Sentry) that come with their own PHP libraries or third-party ones. In my research, I came across one tool, Honeybadger, that did what I wanted and they had one awesome policy.

We believe that an error management system built specifically for Ruby will be 10x better than any one-size-fits-all option.

I thought I want something like that for PHP and its frameworks/platforms. Where it’s someone who actually uses PHP and, most importantly, wants to use it. There’s plenty of language options out there and even more PHP haters so it would be nice to have someone who’s building a product where PHP isn’t an afterthought.

Hey, I know this problem! …and I know PHP!

And all I want is for something like Honeybadger to exist in PHP. So when I was brainstorming my B2B business for the app challenge, this was the first thing I thought about.

So that desire to see this exist got me to create Helthe.

Helthe helps you fix those production errors

My goal is to make Helthe the world-class error monitoring service that PHP deserves. You’ll get more than an alert, a log entry or a stack trace. You’ll get a tool designed to give you the information you need to solve those bugs faster without all the hassle.

If you are interested in having a better handle on your production server issues, check out for details. Otherwise, just keep checking back on how things are going. I’ll be posting regularly and sharing as much as possible of what I have been learning.

I will also be posting about production server topics and other tools you can use. So stay tuned!

Feel free to leave a comment below or discuss on Hacker News.

P.S. If you’d like to keep up to date with my progress, leave your email below!


PHP App Challenge

So I decided to stop my focus on a health for the immediate future. I might do a post-mortem of some sort eventually. That said, I’m still looking into making some form of recurring revenue so I am taking what I have learned over the last year and using it to build a PHP app and, in the vain of what Nathan Barry did with his Web App Challenge, I will try to turn this into a 6 month challenge.


So to give myself some focus, I am going to try to give myself some goals for the challenge over next 6 months.

Hit a recurring revenue of 1000$

I want to build enough recurring revenue to offset my total monthly expenses which are between 600$ and 1000$ (!). This might be a bit a bit optimistic considering what I have read from other bootstrappers. Even with my ramen lifestyle, I want to stop hemorrhaging money. So that’s the goal!

Leverage my competitive advantages

This would definitely come up in my health app post-mortem, but I think it’s clear to me now as a first time bootstrapper that I should not throw away my competitive advantage. So with that in mind, I want to leverage my longtime involvement with the WordPress community and the fact that I work primarily with PHP (gasp!).

So I would want to build a service that is useful to both the WordPress community and the rest of PHP community.

Document my journey

I’ve been writing a bit more consistently, but still not regularly enough. I want to document as much of this as possible and my refocus on programming problems should hopefully help my writing. We’ll see! This is almost a running joke at this point for me.

Let’s get started

Actually, I cheated a bit!  I have already run through a few ideas and did some quick validation through the WordPress Montréal Facebook group. I’ve been doing a small proof of concept to start to see if it is possible, but I am solving a pain I have had over the past year and at my past employment as well. I hope to be able to do a long-form marketing site and a follow-up post shortly!

P.S. If you’d like to keep up to date with my progress, leave your email below!