How much to scratch your own itch as a Startup?

Let me first define the itch concept – the itch here on in will refer to how far to take of your own opinions and desires of how a piece of software should operate.

So the question is from the title:

Q: How much to scratch your own itch as a startup?

Let me answer this right up front:

A: The correct amount.

Off the back of the Thursday night WDYK event, some Startup and User Experience talking points were raised that I wanted to discuss. I started off by trying to fit it in to the last post, but it didn’t quite fit there. I’m working in a Startupesque environment right now and just wanted to put some ideas down on ‘paper’, so here goes…


The statement that sent me off on this thought path was “don’t just scratch your own itch“, it’s good that Joel reminded the audience of this. Often as software developers we inject too much of our own usability ideas into the software being built. This falls over when we eventually realise this is not how typical users of our application would like to use it, even if they are other software developers. What I’m currently working on is not a core software engineer’s tool, say like bug tracking software. It is targeted at a specific type of user and process. But of course we developers often put our ‘application user’ hat on as we build features. Knowing that we’re building the system for someone other than ourselves doesn’t inhibit members of our development team from having strong opinions on how it should operate. This isn’t a bad thing…

Start scratching

There is something in the argument of “scratching your own itch” being beneficial – it is a reasonable starting point to turning your idea into a functioning application. But you always need to keep in mind your needs aren’t going to be exactly those of the customer. There’s a fair bit of this kind of opinion floating around on blogs: “Focusing on our own problems doesn’t necessarily mean we’re solving other people’s problems, or solving problems that matter at scale“- Ben Yoskovitz, source.

When subject matter experience/expertise comes in to play in building the application, you possibly are focussing on your interpretation of the problems that do matter. You can’t always get the cleanest/best problem definition from your users. So you go on to manage the itch combining the expertise and opinion with some user experience analysis. Your team probably has a vision of what the application will be about, heading towards hopefully at least one killer feature/aspect that makes your product stand out. So you go forward combining your ideas and refining with some user testing, now days focussed around the users experience and flow through the application.

Scratch right

This is how you get to that magical place which is the correct amount of scratching your own itch. Have the application be capable of (within reason) all you desire, but reign that in to simpler flows refined by actual results of real users navigating through the system to achieve their normal expectation of work supported by the system.

When my reaches that magical place, I’ll share what it took to get there, but for now it’s just an objective off in the not too far distance.

Scratch well

Joel describing his own start-up raised some great points about not needing venture capital, and how your product would likely be better off without it. There’s no financial pressure from the investor wanting to cash out sometime down the track. The way you do this is by:

1. Make something people want,
2. Make it better than what is out there,
3. Tell people about it.

That last point was a great theme to touch on, Mark had his ideas on this which were about going out to find your users, and not just shouting as he put it (a company blog, a company twitter account). Finding and engaging with users is critical. This is what it will take to get the widest range of feedback to help build your application. But it needs to be guided into a solution that’s not something that has come out of a very large handful of a ‘committee design meetings’.

As an FYI; Joel was Joel Friedlaender – Founder at Red Guava and Mark was Mark Mansour – Founder at Agile Bench

Web Directions South – What Do You Know? Night in Melbourne

Last night Thursday 23rd August 2012, I went along the What Do You Know? event held at The Appartment a great little place I used to frequent when I was working on Exhibition Street.

Earlier this year I was at the Web Directions South Code event, so anything put on the Web Directions South team is great and you should attend. In particular the up coming conference in mid October 2012, Sydney.

So back to Thursday nights event. There were 12 lightning talks, each 5 minutes long, I’ll list them off with links to what was most interesting / their entire presentation.

I wanted to talk about a few that stood out to me, mostly because it’s relevant to what is happening at Picnic Software at the moment.

The 4 presentations that stood out as very relevant to what we’re doing at Picnic Software were:

  • Mark – 5 Simple Things You’ll Forget When You Start a Startup
  • Joel – DevOps for Startups: Tales from the trenches
  • Matt – What the $%&# is UX Design?
  • Will – The User is Drunk

I started off by trying to fit it in to this post, but it ended up longer than I expected so it’s here: How much to scratch your own itch as a Startup?.

Summary of the event with links, in order of appearance:

The State of Our Web Performance Union
John Bristowe, @JohnBristowe

Content being deliver over the web is getting larger faster than bandwidth increases. Aim for performance. Have a look at a data trends

DevOps for Startups: Tales from the trenches
Lucas Chan, @geekylucas

Monitor and be ready for spikes. Uptime is critical. Don’t build what you can rent.

What the $%&# is UX Design?
Matt Magain, @mattymcg

Watch this on YouTube and check out

A whirlwind tour of D3.js
Tony Milne, @tonymilne

It’s very powerful, check it out

A brief introduction to the Gamepad API
Anette Bergo, @anettebgo

Getting Sourcey with Javascript
Michael Mifsud, @xzyfer

Source Maps are the future of debugging the web –

Startup Myths Debunked
Joel Friedlaender, @jfriedlaender

Named some common myths that are all likely wrong; failure is high e.g. 9 in 10 Startups fail, your idea is worthless, you need venture capital, the only costs are your time.

CSS checkboxes and the ridiculous things you can build with them
Ryan Seddon, @ryanseddon

50 handy things you’ve never heard of
Charlie Somerville, @charliesome

From zero to superpimp mobile web app using Tres
Julio Cesar Ody, @julio_ody

Julio amazingly wrote some non-trivial JavaScript using Backbone.js and his library:

The User is Drunk
Will Dayble, @willdayble

Good UI is ‘not there’, say things twice (icon and words), you can’t beat over the shoulder testing (watching your user).

5 Simple Things You’ll Forget When You Start a Startup
Mark Mansour, @markmansour

Marketing (is critical and not easy), Product (focus on benefits and customers), Promotion (talk to customers), Price (Tiers and known costs for customers), Place (don’t shout at your customers, go find them)

Automating IIS actions with PowerShell – Create Multiple Sites

I’m working towards a more complex SignalR based post, but in the mean time part of the work on that involves setting up a few ASP.NET web apps.

If you’re after a more comprehensive guide check out this post on by Thomas Deml. I’ve summarised the steps required to get some basic .NET 4 web applications deployed.

To create N identical websites in local IIS, each with an incrementing name Id. Each linked to the same application directory. The exact reason as to why will come in a future post, for now consider it an exercise in manipulating IIS via PowerShell.

Step 1 – Ensure you’re running the scripts in x86 mode.

Which seems quite common a problem, with a stackoverflow question. I haven’t worked a way around this yet, but this is the error when not running as x86:

New-Item : Cannot retrieve the dynamic parameters for the cmdlet. Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154.
At line:1 char:9
+ New-Item <<<< AppPools\test-app-pool
+ CategoryInfo : InvalidArgument: (:) [New-Item], ParameterBindingException
+ FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.PowerShell.Commands.NewItemCommand

Step 2 – Import-Module WebAdministration
This loads the IIS namespace which allows you to just navigate in the same way you would the filesystem

> CD IIS:\

Step 3 – Create & Configure App Pool

    New-Item AppPools\test.pool

    Set-ItemProperty IIS:\AppPools\test.pool -name "enable32BitAppOnWin64" -Value "true"

    Set-ItemProperty IIS:\AppPools\test.pool -name "managedRuntimeVersion" -Value "v4.0"

NOTE: here I didn’t have any luck storing the app pool path in a variable then using Set-ItemProperty, hence the repeating.

Step 4 – Variables

    $sitesToCreate = 10
    $path = "C:\dev\project-x\App.Web"
    $appPool = "test.pool"

Step 5 – Create Site & Link AppPool Loop

For N(10) to zero:

  • Create a new site
  • Set binding info and physical path
  • Set the app pool
    while ($sitesToCreate -gt 0)
        $siteName = "s" + $sitesToCreate + ".site.local"
        $siteWithIISPrefix = "IIS:\Sites\" + $siteName
        Write-Host "Creating: " $siteName
        $site = New-Item $siteWithIISPrefix -bindings @{protocol="http";bindingInformation="*:80:" + $siteName } -physicalPath $path
        Set-ItemProperty IIS:\Sites\$siteName -name applicationPool -value $appPool

Note: ‘appPool’ is a text variable, not the ‘Get-Item’. Set-ItemProperty operates on a path not a variable representing the item.

We’re done

One last note, to get these to resolve correctly on your local developer machine you’ll need to modify your hosts file.

IIS multisite

The complete code up as a Github Gist.

Capturing client side JavaScript errors for later analysis

We’re getting close to pushing an application to a larger set of test users, and we’ll be interested in what happens when a larger variety of machine configurations (browsers and operating systems) and of course user actions encounter errors.

We started with simply catching any server side errors, and log them to a single database table (separate database to application).

To achieve this part of it, it is simple as having a very lightweight database connection mechanism to insert this log entry record, this way if there was an error with our applications standard database access mechanism we could also capture that.

In this fashion we can be reasonably sure that anything short of major production environment failure (network infrastructure / machine specific) that we’ll be able to capture errors while the system is being used. Those types of issues will be handled differently.

Then we realised it would be just as helpful to capture and store client side JavaScript errors in a similar fashion.


The JavaScript error handler looks like this, making use of window.error:

window.$debug.globalErrorHandler = function () {
  window.onerror = function (m, u, l) {
      url: '/Error/Occurred',
      type: 'POST',
      dataType: 'json',
      data: JSON.stringify({ errorMsg: m, url: u, line: l, uri: window.location.href }),
      contentType: 'application/json; charset=utf-8',
    return true;

An extra note here is I came across a JS library that offered a common ‘printStackTrace()’ method. Created by Eric Wendelingithub project. Which doesn’t work how I would have hoped it would have worked in our global error handler, but that’s the nature of the error handler event.

Never the less it does look quite helpful, to make use of it you need to have a specific try { } catch { } block around something that may fail. Checkout the readme on the github project page.

Back to the main focus of this post…

We can also decide to call $debug.globalErrorHandler() method in some central part of the web application, so that later it doesn’t have to be always turned on.


The MVC side of this is even simpler, since our users are logged in while using the application, we have ‘context’ information about them, so that’s one extra useful piece of information we can capture as part of the error.

public class ErrorController
  public void Occurred(ClientSideJavaScriptException error)
    // this context in our application represents the user, so we know who experienced the error.
    error.User = _userContext.UserName;

    // we send this off elsewhere to be persisted, you could simply persist it here

The ClientSideJavaScriptException class simply has the properties required to send over the information from the ajax post.

public class ClientSideJavaScriptException
  public string ErrorMsg { get; set; }
  public string Url { get; set; }
  public string Line { get; set; }


Finally the persistence logic here is via the Micro.ORM NPoco selected because Adam said it was good 😉 and the Nuget Package helped.

Db = new Database("configuration_key_name");

Db.Insert(new Details
  OccurredWhere = "client-side-js",
  ExceptionMessage = errorDetails.ErrorMsg,
  When = DateTime.Now,
  StackTrace = errorDetails.Stack,
  Method = "Line Number:" + errorDetails.Line