Michiel van Vlaardingen

If you’re in a bootstrapped startup,  looking at your bank account probably isn’t the most cheerful experience. You are probably still investing all that comes in and maybe even a bit more. So how do you know that you are still on the right track?

1. Are we there yet? Are you running a profit?  If you don’t know… do your homework and get back here ASAP.  If you are making a profit… why are you even reading this article?

2. Is there a future? So you are not running a profit… but could you?  If you would cut all development and investment related costs  and  would coast with whatever you have right now…  Would there be enough money for you to sustain this operation? If so: you are already investing in making more profit in the future, make sure though that the extra investments really contribute to your goals.

3. Can we make it? If your revenue is not high enough right now, you are walking a thin line. Is there enough money expected to bridge the gap?  Find out when you can get to #2 and sum all losses you expect to make in between.  Do you have that kind of money or can you get it?  This may be the time to adjust your plans,  either cut some costs or get some extra money.

4. Does it matter? What if you would sell everything right now? Would it be enough to cover debts and the income you missed?  If so, maybe it’s good to stop bootstrapping and get some money to prevent this value you’ve created to be wasted.   Keep in mind that you don’t want to wait till the last minute, because if you’re out of options… you are going to be a bargain.

5. Do you love it? Maybe your business isn’t that dependent on money, still, you are investing a lot of time in it, right?  If it’s not worth the money, at least make it worth for yourself.  Is this really the thing you love most to spend all your time on?    If you feel committed to a project you don’t really love anymore,  find someone who can take over,  or change it so that you can love it again.

SEOmoz seemed to have some nice tools,  so  we decided to give it’s PRO account a try.     And indeed the tools are quite nice.   I especially like the idea of Linkscape and  Ranktracker.    Linkscape shows you exactly what pages are linking to your site.  And better: you can easily filter them to see which do not come from your own website, which ones have  nofollow on them, etc.     Ranktracker does what you expect from the name:   track  search engine positions for different keywords over time.    There is a bunch of other tools as well, but those are not really impressive and maybe even a bit outdated.

However,  the site and tools are SLOW,   a significant portion of my requests  fails or take ages.     I’ve tested it during multiple days, so it’s not a one-time thing.    In my opinion  as a programmer I’m better of reproducing the tools with some small scripts,  because unresponsive sites really annoy me, especially if I pay $79 a month for them.     I do not think  I lost that first payment though, because there is also some great paid content over there.  But that’s not nearly enough to justify paying  $79 every month.

An Idea I do like it that I can take a questionnaire after I cancel  and get another week for free.   Because on our sites people usually don’t want to take the effort to tell us why they cancel.

At MovingLabs we really believe in creating all our tools, but as we need many, most are not really finished. Fine for us, but not so much if we need to collaborate with others.  We do have our own project tools like  TeamSpinner and FlexLists, but not everyone likes them in their current state.    Therefore we decided to sign up for the 30 day evaluation of Basecamp. Something that receives so much positive attention must be spectacular , right?

What I expected,  from what I’ve read and heard, was a clean and simple interface where those parts that are there are quick, effective and perfect.    The clean and simple part is definitely true,  there is no visual waste and I can quicly find stuff.  However speed, effectiveness and perfection are the things that I can’t find.

The first thing I noticed is that it’s actually quite slow,  maybe because it’s servers are in the US, but in terms of speed it feels like the  Java Enterprise intranet application that I worked on years ago.

Second thing is that it still has many rough edges that I would have expected to be fixed by now:

• No error or resubmit, just forever ‘busy’  when the connection drops while doing an ajax submit ( Gmail set the standards high on this stuff)
• The main page title is not clickable
• On the message entry form there is not a hint that I can actually use the wiki like syntax
• I can’t click on users anywhere to get some details about them, like which projects I share, what their e-mail is,  etc.

Finally I just miss a very important thing:  I want to set my todo’s  to  ‘busy’ .   I’m just way too used to doing that.

Besides these points it does work fairly well, I do like the way it takes into account that you want to collaborate with multiple parties.  However,  it’s not nearly good enough to cure the  ‘not invented here’ feeling.  Luckily the party we tried to collaborate with agrees with us, so seems like we need to fix TeamSpinner after all…

My previous post was a bit generic, but now I’ve encountered the perfect example of how building a Framework slows you down:

Lets say we are building basic user account confirmation. In a plain-php way I would write:
mail($email, “Your account confirmation”, “….”);

Now in our framework it has evolved to something like:
mail($email,  $settings->getSetting(CONFIRMATION_MAIL_TITLE), “…”);
and the actual text is loaded from the settings table in the database (so our non-tech partners can edit as well).  So all is now configurable and nice and quick and smart right?

NO, because in a new project, the database is clean, so I get a nice “confirmation.mail.title setting is not defined”.    And now this is where I slow myself down:  Instead of just adding this entry to the database I think:  hey, I shouldn’t get this error, this should have a default setting.   So now instead of having to write this one simple line of code I have to:
– find a way to store all default settings in some file in the framework distribution
– adjust the settings mechanism to use those defaults if there is nothing in the DB
– retrieve all data in the settings table from a previous project and store it in the file

And as soon as I have this thought cross my mind, the focus on the original project is gone and we are back at the infinite task of the perfect framework.

If you develop a lot of projects and are a bit like us, you will recognize this: the reusability dream.  It starts of with a little itch that you are not taking advantage of the knowledge and work in the previous project.  You start with some simple database handling and utility functions and all is fine. For a while…

The next stage is actually creating reusable functionality….   The reason is that you know it will haunt you do the same thing in multiple projects  using copy/paste  as it will need to be fixed some time.

This is also the point where your library turns into a framework: Everything needs to be done in a particular way to fit in your nice reusable scheme of things.  Your project no longer just uses a few nice functions,  it completely depends on it.

As I’ve written before the reason I like plain PHP is what I call the notion of proportional time.  The time you spend is proportional to the complexity of the feature you are building.

The problem with frameworks is that they have smart things built in. The framework makes it easy to do stuff that usually takes much more time. However, it’s almost never smart enough. At this time your framework has evolved so much that every time you will have to pick your poison: either go through a painful adaptation to your framework OR recreate it without your framework and go through the painful tinkering an bugfixing that’s all built into the framework… how frustrating.

In our case this stage expresses itself in SLOW development.  Every small step forward becomes way more complex than the actual feature that you need to built.  It’s completely against the principle of proportional time.  You are locked in your own Framework.

Now is the time that you need to consider whether or not: worse before better applies or that it’s just going downhill.    Two years ago we had a framework where the latter was clearly the case and we just had to drop it.   The problem with it was that it was really an all-or-nothing approach.  In our new framework we can easily take just a step back and use only part of the framework until we have clear ideas about the next level.   We still experience the  locked-in situation from time to time, but it’s much easier to get past it.

Our path to Framework enlightenment has the following steps:

• No collisions: make sure that the library/framework does not collide with other code, this will mean that you can drop it into an existing project without the need to rewrite it first
• Layers: create layers of tools, functions and abstractions. If one layer is to restrictive, you can at least use all tools from the other layers below it
• the framework needs to be out of the way:  You must always be able to do things outside the framework and still access it’s data.
• Everything needs configuration and even more important: defaults
• Override everything: be able to replace small parts of functionality without the need to recreate it completely.
• Constants do not exist:   at some point you will want to be able to manipulate it with code
• Move everything to the framework: if you want to reuse it, don’t create it inside your project directory
• Have a (documented) process (including best practices) to create new things for and using the framework.

We are not there yet, but are confident that this time that the benefits outweigh the extra effort.