Tag Archives: Helthe

Finalizing Error Management Design

How long does it take me to come up with a design? Well, as you can see in the gap in posts, the answer seems to be a week. I started the week with the totally wrong assumption that designing the error management page would take me two days tops.

Design is not a quick process

Early Bootstrap Mockup
Early Bootstrap Mockup

After two days, I hadn’t even wrapped my head around the direction I wanted to go with the design. I was still exploring patterns, how other products used them and which ones were relevant to Helthe.

While I had some hand drawn sketches to work with, transforming those sketches into mockups was not easy at all in the end. I am not a quick with CSS as I am with regular code.

False needs

In my previous post, I discussed the needs of the user. After some reflection, I concluded that there were three needs that were not needed currently. So I made some additional cuts to simplify things. Those were:

  • He needs to be able to see if that error is assigned to anyone.
  • He needs to be able to assign the error to a team member.
  • He needs to be able to comment on the error.

All these features are collaborative in nature, but as I sketched and mocked them I had difficulty seeing their need in the current product state. I had a friend do a quick review of an early sketch and he also told me that they were not needed at the moment.

The main issue is that collaboration needs like commenting and assignment are only useful to the user if they integrate with the tools that the user is using. The user does not need another application to check for comments, assignments, etc. It needs to integrate with the tools the user is already using.

Could I be that tool? Maybe, but it seems premature to think so. It can be added to the product at a later date.

So I decided to cut the features till I could think of them in the context of the 3rd party integrations.

Navigation requires its own scope

This is something else I realized along the way. I was working on mocking up the navigation (like a breadcrumb), but I found it really hard to do so without having multiple pieces to put together.

You have to really think about the user flow and how users will be moving from screen to screen. With just the error screen, I had a really hard time visualizing it.

This might also be due to inexperience on my part, but I felt better moving it into its own scope to be dealt with later.

Current Design

View Error : Helthe
Near Final Mockup

As of this afternoon, this is the current design of the error management page. I want to share some of the design decisions that I took. As I mentioned in my notes previously, there’s two jobs that this screen needs to accomplish. Those were:

  1. He got a new alert and wants to get further details so that he can properly evaluate its severity and possibly assign it to a team member.
  2. He got assigned the error (or came on his own) and is here to solve it. He needs to have all the information required to reproduce it so that it can be fixed.


The header section is dedicated almost exclusively to the first job. At a quick glance, the user is able to see all the important information about the error.

The user can do the quick operations that I had highlighted in my notes and he also has access to the big picture details.

Using colours

The most important design challenge for me was that I wanted the user to be able to determine the error severity very quickly. Early on in the design process, I decided to use a colour scheme to communicate that.

When a user lands on the page, he immediately sees the coloured border next to the error text. The error text is the first thing the user will read, but the eye is quickly drawn to the coloured label right underneath the error text. That label tells the user the error type.

As I was iterating, I wanted to reinforce this colour scheme further and I thought that the tabs was a place to do it. This adds a reminder as the user is scanning down to the different sections. It also keeps the whole palette consistent for the page.

The result is that, when the user lands on the page, he will immediately know the severity of the error in question.




I renamed the ignore error button to snooze. That was suggested to me by a friend during an initial review. I liked the term a lot. Snooze implies a temporary respite before you become alerted again which is really what users want to do usually.

What I also liked was that snooze is based on rules which can be very open-ended. As the product involves, it could be a timeframe (a week), till the next deploy (once I track deploys) or indefinitely.

Overall, it’s a small detail, but one that I felt brought a lot of clarity to the user.

Recent activity

Sentry has this and I thought it was very important to incorporate it. When someone comes here, they need to know what has been happening quickly. Recent activity is a pattern that allows for this. On top of that, it is very flexible. Since anything can be an activity.

Bottom section

I did some work on the bottom section. The summary has roughly all the information you would need, but will probably need a bit more polish once I started wiring the application code. I am not 100% sure that the “reported at” timestamp should just be in the table.

I didn’t style the trace or any of the other tabs yet which might require a bit of time, but I am going to wait a see what the data and the output looks like to begin.

Off to the lower layers

Now that the majority of the design is wrapped off, I am moving on to the lower layers to finish off the error management scope.

Notes on error management design

In my previous post, I described the process I would be taking to continue the development of Helthe. We concluded that the scope of the project that would offer the largest learning opportunity would be the error management piece. The past two days I have been working on design notes for the error details screen that follow partly Ryan Singer’s post on design process. I am editing them and sharing them with you.

What is error management?

One thing that I didn’t do is define what is error management. In the context of Helthe, error management is what allows the user to interact with the collected errors and work with them. The main application screen involved is the error details screen. On the application layer, it involves grouping similar errors together in a useful manner.

Why are they here?

The first thing I did is try to think of all the situation that would lead the user to this part of the system. I came up with the following:

  • Most users will come because they got an alert from the system
    • New Error Alert
    • Error Assignment Alert
  • Some users will come from the dashboard
  • Some users were browsing all the project errors

What are the jobs(s)?

What does the error details screen help with? What is its job? What does it help the user with? This is probably the most important screen for the user. Helthe is supposed to give a lot of value to the user here so what are the jobs that the user expects help with.

I came to the conclusion that when a user comes to this screen, he is here for two different jobs:

  1. He got a new alert and wants to get further details so that he can properly evaluate its severity and possibly assign it to a team member
  2. He got assigned the error (or came on his own) and is here to solve it. He needs to have all the information required to reproduce it so that it can be fixed.

Defining the value for each job

The two jobs are very specific, but there is overlap. I’ll be attempting to define the needs of the user for each job so that product gives the best value possible in each case.

What does job #1 need?

Job #1 describes what is expected of the error details page when some one lands on it. A user that just received an alert needs a good summary with the important information readily available. While the summary needs to be useful to both jobs, users doing job #1 are the ones that need to be 100% satisfied by it.

So a user clicks on the alert email (from desktop or phone), he gets to the error details. What capabilities does he need to do his job? I have tried to order them in order of importance.

  • He needs to be able to see the status of the error (Resolved or Unresolved)
  • He needs to be able to determine the severity of the error
  • He needs to be able to see the error text
  • He needs to be able to determine if this error is new or if it is a regression
  • He needs to be able to ignore the error because it can’t be fixed now
  • He needs to be able to see if that error is assigned to anyone
  • He needs to be able to assign the error to a team member
  • He needs to know when it happened (First Seen/Last Seen)

This is quite a few items, but the user needs to be able to discern all of them easily at a glance even on a mobile device.

What does job #2 need?

So a user that is looking to solve an error, what does he need to do his job? A lot of what was described in Job #1 is useful initially, but he needs to have additional heavy-duty capabilities to actually resolve the error.

  • He needs to know the URL and HTTP request method that caused the error
  • He needs to know where the error happened (File and Line No)
  • He needs to be able to view and navigate between similar errors
  • He needs to be able to access specific error details
    • Trace
    • Environment Variables
    • Application Context (e.g. User Logged In, Controller, Plugins)
    • Browser Details
  • He needs to be able to mark an error as resolved
  • He needs to be able to comment on the error

Design in the works

I am working on the design of the page. I hope to be able to share the result and how this influenced it soon.

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!

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.

Why it is only PHP

Looking for an update on what I did yesterday? Well I did NOTHING. I felt quite bad about it, but if there’s something my gym habit has taught me is that you can’t be perfect every day. But today I was ready to get things done!

It is worth noting that it is the last day to work on your roadmap for Week of Hustle. Tomorrow, you have to ship things out so I was determined to get through the rest of it.

A week ago by the campfire

Last sunday following the publication of my roadmap, I had a discussion in the JFDI campfire chat room with Andy Parkinson about Helthe and what the service was. The important part of the conversation is found below.

Campfire ChatThe main takeaway that I took is that I needed to really double down on what it meant to the user to have a solution for PHP. The other popular languages at the moment tend to have one dominant framework (Django for Python and Rails for Ruby), but that’s not the case for PHP and that needs to be better explained.

PHP is 80% of the web

PHP is so prevalent for many reasons, but the important point is that PHP is represented by more than just a framework. It is used to run web dominant CMSes and E-Commerce platforms as well as various frameworks so it’s not realistic to expect one PHP library to be adequate for each. I definitely don’t believe it is. And that’s where I draw my line.

WordPress is the best example of that. I already did an exhaustive analysis of WordPress errors and how they are handled. A regular PHP library would only capture a fraction of the problems that could happen within a WordPress installation. It’s especially complex because WordPress is so defensive in its way of handling problems.

I don’t have an issue with that per say because it makes WordPress very user-friendly which is one of its core values. It does, however, put an increased burden on the programmer who is looking for the cause of problems. This can lead to dangerous practices like cowboy coding because it’s just so hard to know what is going on at times.

We meet again copywriting

With all these ideas swirling in my head, I set to work modifying my marketing site copy.

Now I have a confession to make, whenever I have to do copywriting, I want to go hide somewhere and forget about it. It’s one of the many skills I need to build, but it’s definitely the one that makes me feel the clumsiest. I feel like Fry (Futurama) trying to play the holophor for Leela.

You have well constructed ideas in your head, but you have to put them out there and hope they get shared properly.

Before Screenshot

I wanted to modify the section that discussed the more PHP centric benefits for the user to be more descriptive and explain some of the  issues I brought up earlier in the post. After 4 hours, I got a result I was satisfied with.

After Screenshot
After Screenshot

I do actually think it is an improvement over the old version. I didn’t add the logos because I couldn’t make them look good on the page with the responsive layout so I kept them out. I am curious to know if logos are something you would consider important so let me know in the comments.

I did a small modification to the FAQ to say that the deadline had passed, but I was still working on it.

This goes up tomorrow

I’ll be pushing all this out tomorrow, but will be keeping the work I did on the account creation and API disabled. I’ll be writing up my thoughts on the experience as well.

Keep up with my progress

I have been bad and haven’t sent emails everyday as I should, this is the next thing I want to spend time tackling. I’ll be sending a detailed recap at the end of the project to my mailing list. You can subscribe here. You will also get all the info when things are ready for testing.

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 customer.io, 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 !