Self-Employed Software Developer

Delivering software is … fun!

When it comes to build a products under contract, one of the most challenging things that developers have to manage – specifically if they’re also serving as project management – is client expectations.

To be clear: outside of 8BIT, I’m also self-employed and spend a portion of my time building WordPress-based products for others. Generally, I build custom plugins and web applications.

Anyway, like anyone that makes the jump to self-employment, it wasn’t with out its share of learning curves.

It’s one thing to talk to people who are somewhat familiar with the web, with software, or with how similar projects work, but it’s a completely different situation to work with people who know what they want but aren’t exactly sure what all it entails.

For what it’s worth, here are three things that I’ve found useful in setting expectations, planning projects, and delivering products as a self-employed software developer.

1. Setting Expectations

Expectation Failed

Don’t be this, dog.

Regardless of the client’s experience, I think that it’s always safe to gather as much information as possible rather than assume anything. By this, I mean not only have the user walk through exactly they want, but provide examples of other sites, plugins, applications, etc., from which they’re drawing inspiration.

On top of that, I’ve found that delivering preliminary sketches and diagrams using applications such as Paper can go a long way in clarifying and solidifying an idea.

Ultimately, the point is to not only to get a solid idea for what the client wants, but to distill the project down to its core feature set – its MVP, even – to identify what’s core for launch and what’s the nice-to-haves that can come later.

This helps to define what you, as the developer, are going to deliver, and what the client can expect delivered.

2. Planning Projects

This is your project plan?

McKayla is not impressed with your project plan.

After expectations have been set, project planning can be one of those things that gets really complicated really quickly especially given the variety of tools that we have.

Personally, I think that some people are more interested in using project management tools for the sake of saying that they use them rather than actually use them. But I digress.

Anyway, I don’t have a fixed way that I manage projects. Sometimes I use Basecamp, sometimes I use a GitHub wiki, and sometimes I simply use emails. It all depends on the client.

Here’s the thing: there’s something to be said for being flexible to their needs. After all, they are trusting you to deliver a product that’s useful for them and that’s contingent upon an agreed upon schedule.

I’ve found that it can go a long way to work with their project management system or style (or at least find a suitable compromise) to not only ease the delivery of the project, but to instill a level of confidence that work is actually being accomplished.

That said, I typically break a project down into milestones and each milestone into tasks. I’ll then provide at least weekly updates of the status of the issues and will do weekly deployments to the staging environment on which the client can actually see the working version of the application.

After all, the point of project management is to give a visual representation of the progress of a project.

3. Delivering The Product

Product Delivery

Sometimes, developers actually act like this.

When it comes to delivering the actual product, this should not be a single-step process. Aside from weekly deliverables (or whatever interval you prefer), the hand-off should follow several phases:

  1. Deploy the application the production environment
  2. Set it up, configure it, populate it with data necessary to get the site and/or application rolling
  3. Have the user work with the environment
  4. Hand it off for final delivery

Typically, I find the most trouble to be in the third step. Despite the fact that a staging environment should mitigate any issues encountered, something will almost always go wrong at this point.

And if you’re expecting it, then it’s no big deal. It’s a matter of working through any questions, comments, and/or small tweaks necessary to deploy.

Finally, at the hand off, there’s a clear line of communication stating that the project is completed and anything afterwards would constitute maintenance, a new project, or another contract arrangement.

This All Works?

I’m not saying that this is the way that all self-employed developers work. I’m not even trying to make the claim that this how projects should be run.

Instead, I’m saying that this is what I’ve found to prove successful when running projects – even several simultaneously – in the course of the time that I’ve worked as a the person responsible for running a business.

Of course, I’m always interested in knowing what others have found useful so feel free to share ’em.


Join the conversation! 4 Comments

  1. Great post, loving working with you and seeing this in action. Very precessional and well thought out. I hope other developers are reading this!

  2. One of the biggest challenges for me has always been managing “feature creep”. I started adapting Scrum methods and integrating them in my work flow to mitigate this, using Trello to keep product- and sprint backlogs.

    How do you deal with new features that somehow seep into a project mid-stream?

    • Personally, I see this as a two-phase issue.

      First, I make sure that requirements are locked earlier on. This takes a bit of experience to note what constitutes an MVP, but once you’ve got it, you’re golden.

      Secondly, once the requirements and features and locked in, it’s easy to say that a requested feature isn’t part of the initial requires so they need to be pushed to a backlog for a future version.

      This has been what’s working for me for the past year or so but, then again, I don’t generally work on enterprise level stuff anymore so I can’t say this works in all cases.

Leave a Reply