Seattle Node and Swift Freelance Developer

I worked on several cool projects this summer, but also had some challenging tests of my skills as a freelancer.

The challenges of being a freelancer

Just a few of them…

• Scrambling to find new clients when a long-term project ends unexpectedly.
• Wanting to say yes to a position referred by a friend for fear that offers will stop coming if you say no.
• Taking a short job to bridge to a longer-term job, then having the longer-term job come through too quickly.
• Balancing expectations on availability with clients
  • “I’ll be available next month”  doesn’t mean “I’ll start next at the beginning of next month”
  • “I’m available for four weeks”  doesn’t mean “until the end of next month”

As a freelancer, it’s hard to be strict about exactly what work you want to do and can-do. A good goal is to charge enough so that you can say no to all but the best-fit clients.

There’s a fine line between no projects (or too little work) and too much work. In one case I was trying to work while sick to keep the client happy (not that they asked). I didn’t get better, and I barely ended the project on a positive note. It would’ve been much better to just take the time off up front that I needed to not get sick.

Haiku Deck

I worked at Haiku Deck on an awesome product with a fun team for 2 years. Even though I knew funds were tight, it came as a little bit of a surprise to learn that the budget for my time was used up. The ensuing restructuring made for a chaotic week. As a freelancer (unlike salaried employees), I actually like this dynamic change. It’s a challenge to find fresh problems to sole.

The main issue for me, was that I hadn’t been doing a lot of networking. I had gotten lazy about participating in community events. So when my job dried up, I didn’t have another one to jump to. Or, even a clear definition of what I wanted to the next. I did have a lot of side projects I to work on. So I started work on those and tried to get a quick job through Upwork (previously oDesk) to pay the bills.

Scality via Upwork

I’ve always been enticed by the prospect of finding small projects online that are paid hourly. I love the idea of working remote and on my own time. Someday, I’d like to do this while traveling. I had used oDesk as a client before – hiring writers and developers. But I never signed on as developer to get paid for a project.

I applied to about 10 projects. The application process was time-consuming. I tried to write enough and ask enough questions to distinguish myself from the other applicants. I had to explain why I charge 5 times as much as the other developers. I found a good project that was very clearly specified, the unit tests were even provided.

I landed the project and started work – albeit at 2/3rds my normal rate. Unfortunately, the unit tests did not cover a very important and complicated part of the new functionality. So there were a couple very late nights getting things done in a timely fashion for the client. The project was using node to transfer giant files. I wrote up some of my learnings about subclassing node streams.

I expected starting out with Upwork that I would have to discount my rate. What I didn’t account for was that every minute is logged. I don’t mind the invasion of privacy, my assumption is that as I gain trust with my clients – they will pay less attention to my hours. However, I didn’t account for the loss of “soft” billable time. I couldn’t charge for meetings. Every time I went to the bathroom,  took lunch, or researched something, I felt like I needed to clock out. This meant that 40 billable hours required about 50 hours of time. It was intense. Especially when trying to impress the client by meeting the deadline.

Of course, once I did a good job, client offered more work at a higher rate. Which is awesome. It was a great way to discover a new client that I wouldn’t have met through my Seattle network. However, At that point in the summer I wasn’t ready to “drink from the fire hose.”

I’m not sure I will return to Upwork because I think I would be more efficient pitching my skills in person (or on the phone), and finding more interesting projects through my network.

Moment

I wanted to work for Mark Barros because he’s an awesome CEO. But also I wanted to work for him because he pulled me up the half pipe during Tough Mudder. I got to help Moment for a few days with a product launch. Specifically, I worked on an order fulfillment system for cool new phone cases and camera lenses.

The interesting thing about working for moment is that it is primarily hardware company. Turns out that’s not a good fit for me. I’ve mostly worked for companies where software is the main product. For a business like Moment, hardware is the product. They rightfully use whatever software necessary to sell and deliver it. In this case it was WordPress with WooCommerce. A frustrating choice for me as a developer – but a logical one for Moment.

Uberhuman

TA McCann wrote a great blog post about his experience killing this startup right before the seed round. It inspired me to write this post. I thought it would be fun to share my perspective.

With a few extra hours during the summer, I joined TA with a couple other developers and designers at his home. We discussed and coded an initial prototype. My job was writing the Node API to send faxes requesting medical records from doctors. Few providers responded. As it turns out, providers have no incentive (despite the law) to share medical records with their patients.

T.A. and I have a great working relationship. I can show up, ask a few questions, and then implement an experiment. It was worth the investment of free time for the possibility of working together. Sadly, we decided not to pursue it and it’s back to being a side project for me.

Photo app

Another great project that I spent considerable time on over the summer was a viral photo app. It is sort of like a Photo booth with a twist. A friend of a friend and I had a similar idea and the three of us started working on it. As I got the prototype going, we narrowed in on an MVP feature set. A big part of this was negotiating ownership of the project. It will hopefully yet see the light of day.

The project was excellent experience with Swift development. I am impressed by how well documented the iOS APIs are. I was also relieved to be writing code that compiled after lots and lots of JavaScript.

Retirement Calculator and Portfolio Creator

To prove my credentials as an iOS developer, I wanted to get an iOS app in the app store. A close relative is a financial advisor. After seeing his website, I realized it would make a straightforward iOS app. I scoped it out and talked to him. Within about 10 days of work we had Retirement Calculator and Portfolio Creator in the App Store.

I was pleasantly surprised that there was zero pushback from Apple. The release process was smooth. As a marketer, the project reinforced the importance engagement for mobile apps. We have new users that have committed valuable megabytes of their phone. We want to keep them using our app. This is a small insight for me – more obvious in mobile than on the web. Orphaned registered users seem that much closer when your code is in for installed on their phone.

Freeway

The project that I’m most excited to be working on is building tools for freelancers. We’re also matching freelancers to projects. I’m going to skip writing about this now because we’ve got some cool stuff in the works. But I did want to share this call I had with freelancers. We’ve been following up with everybody and I’ll have more on this by the end of the year.

Ookla/Formidable

I worked with Per Nilsson and Anna Luisa West from Formidable Labs at Haiku Deck. They were great. I wanted to work with Formidable again. Formidable offered a great project that I couldn’t refuse, helping Ookla launch a data portal.  You’ve probably used speedtest.net – we helped them report on all that great data. The result was a killer product for their clients.

Related

• How to win a bike race
• Recovering from a dislocated shoulder