Why We Do This

Most entrepreneurs know the Starbucks fantasy.  One morning, you’re waiting in line to grab whatever revs you up in the morning.

You’re on autopilot – not thinking about what you’re going to order, but about how you’re going to get through the month.  Is that new product really the right direction?  Is your most recent hire worth it, or should you have hired the other candidate?  Or both?  Or neither?  every thought ends with a question mark.

And then it hits you: Life could be simpler.  By a lot.  You could have less responsibility.  By a lot.

If you really wanted to, you could just close down your company and serve coffee for a living.  Do something well defined.  Repetitive.  Screw up peoples names on cups and not really care all that much.

A job that requires skill – but a totally different set of skills then you have today.

And you spend the two minutes in line watching the people behind the counter.  “I could do that,” you think to yourself.

After all, you’re an entrepreneur, it’s not like you bring home a huge paycheque anyway.  And nobody ever gives you tips, unless we’re talking about unsolicited advice.

About a year and a half ago, I was having a bout of the Starbucks fantasy.  It was lasting for weeks.  All I could think about was how I had so many options, and almost none of them would take as much out of me as running a company.

I was in Toronto visiting my best friend when I let it slip out of my mouth.  “Maybe I don’t even need to keep the company going.  We’re at a good place this year to wrap up our lease.  And I know I could line up other jobs for people easily.”

We let that sit in the air for a minute.  I felt especially tired.  I was trying to launch a product that wasn’t going anywhere.  The airline had just lost my luggage somewhere in New Jersey.  There was money in the bank, but nothing in our sales funnel.

“I’ve known you for ten years,” he said.  “And all you’ve I’ve ever seen you want is to run a company.”

He was right.  When I’m not running a company, my brain spends all it’s spare cycles thinking about starting one up.

And the Starbucks fantasy went away.  And it’s stayed away since.  Ever since the moment when I acknowledged that running a company wasn’t just something I was doing, it was something I was wanting.  Because it’s funny how quickly your brain turns wants into obligations.

If you’re in this place, I hope it’s because it’s something you want to do.  Because it’s something you’re driven to do.  If it’s something you’re just…doing?  That’s not worth it.  Go work at Starbucks.

Update on codeless

It turns out that I’m pretty bad at developing codeless in public.  Luckily I’m half-decent at developing software.  I’m trying to be better at both.

As you might recall, codeless is a different kind of app design tool.  It works with native elements, directly on an iOS device to create an interactive prototype that can be exported to code.  After getting frustrated with the number of static mockups I was seeing, it seemed like the obvious thing to try.

Happily, it’s coming together.  If you’ve got four minutes, check out the quick screencast I put together of a basic maps interface.

It’s getting to the kind of place where we should be collecting email addresses for a beta in a couple months.  If you’re interested, ping me at <a href=“mailto:bob@wholepunk.com”>bob@wholepunk.com</a> and we’ll get you on the list.

Prelude to codeless

I love working on side projects, but I don’t usually talk about them until they’re ready to demo.  

What if I decide this isn’t worth pursuing in six months?  What if this turns out to be vapourware – will that hurt my reputation?  When I go down a blind alley and have to turn around, will I look stupid in front of my peers?  What happens if we get really busy at work and I can’t make any progress for a month?

On the other hand, I have a burning desire to try and build a side project ‘in public’.  I want to get people excited about this project, and I want to see if people are interested in it before I get too far down the path of building it.  I want to build the projects reputation, so that on launch day we’re ready to talk about it confidently.  And I want to tap into the hive mind that is the internet and see if anyone suggests something I never considered.

With that in mind, I’ve decided on a couple things.  I’m going to tell you about a side project I’ve been working on, only a few weeks into it’s life.  I’m going to try to stay open about it, and to tell you about where it’s gone and where it’s heading.  And I’m going to commit to releasing it as open source if I ever decide to put it on the shelf for good.

The problem we’re solving

I find it pretty frustrating how apps are designed right now.  Static mockups are made 

I get really frustrated with apps designed in photoshop…

…because it feels like someone handed me storyboard mockups and claimed they were a completed film.  I’ve been running an consulting company that specializes in mobile development for the last three years, and I’m always annoyed when a designer hands me a photoshop mockup for the app.  Because I know they’re going to want it translated to the screen in a pixel-perfect fashion, despite the fact that they built it in an image editor, and not on the platform.

Here are a few things that commonly fail in translation:

– Font rendering is different across platforms.

– Sometimes things look better on a 30” monitor than a 3.5” device.  Button sizes that look perfectly reasonable in photoshop are usually impossible to hit.

– For that matter, we usually only get photoshop documents for a single size of screen, and it’s usually not the largest or the smallest.  Apps designed this way are usually too tight on small screens and too spread out on large ones.

– Often there’s a graphic effect they’ve carefully tweaked, but want rendered live.  A blur over content is a common example.

These are all things that get screwed up in translation.  I’d like to be able to design apps on the actual device, with the native elements, so that I know things will render the same way in the final product.

We’re also wasting a lot of time and money

In the current model of handing off mockups, two expensive people doing the same work over.  The designer does a great job in photoshop, then the developer has to do the *same great job* in code.  And the developer is probably going to miss some subtleties.  Just look at how hard it is to do those ‘find ten differences’ puzzles you see in newspapers. Right now, every screen of the app is one of those.

No, I’m not saying the entire job of a designer is positioning elements, but the final output is a graphic file.

The ultimate aim for a mobile design app would be to output actual compilable code at the end.  Let the designer do their job in the *actual medium*, and let the developer take that work and build on it, not redo it.


codeless is an iPad app I’ve been working on.  It’s in the early days right now, only supporting a few things like view positioning and some basic property editing.  But it’s going to be great.

Think of it as a cross between Photoshop and Interface Builder, with a little bit of Invision App thrown in for good measure.

It’s ugly as sin right now.  Here’s the first screenshot.

codeless screenshot

You can probably tell, there’s quite a ways to go.  Come with me.

Concept and Execution

Matt Gemmell tweeted this lovely concept of the Macintosh Nueu from Curved Labs.  It’s a stunning piece of design work that immediately sets off a twinge of nostalgia.  Familiar in both 1984 and 2015, the design resonates.

I loved the design of the original all-in-one Macs.  I keep a Mac Plus and a Classic II on the bookshelf in my office.  Maybe it’s just because I used them in my childhood, but they evoke a sense of wonder that more modern technology struggles to match.

With few exceptions though, I dislike concepts.  They give me a sour feeling in my gut.  As someone who’s often tasked with turning bright ideas into reality, I’m deeply uncomfortable with presenting a cool idea in such a factual way.  Concepts make for great art, but they’re terribly misleading when it comes to portraying what we should actually do.

Executing on an idea brings forward all the sharp corners and rough edges.  We almost never know what the actual problems in a development cycle are going to be until we’ve finished the first pass at implementation.  Oh sure, you can spot some of the dangers from afar, but that doesn’t mean there aren’t more lurking horrors that will require a course correction midstream.

If you can execute on the idea and it’s still a good idea, you’ve got a winner.


Yesterday I missed a day of blogging.  It’s just a couple days until the end of my 30 day challenge and I feel like I’m running out of steam.

I should probably write something about the Apple Watch, but it’s hard to find the time.  That, and the payments infrastructure is far more interesting, even if the watch is grabbing most of the press attention.

But, as an old boss of mine says, that’s a tomorrow job.

How Long to Clone It?

We’ve recently been putting the finishing touches on a new product at work.  I’ve been taking it around town and chatting about it to friends and founders, seeing what their response is.  I’ve been tuning the story and figuring out reactions.

One of the intriguing questions that people ask me when I demo it is “How long do you thing it’d take for someone to clone it?”

It’s a flattering question, because it implies that we might have created something valuable enough here to be worth ripping off.    It’s also an immensely scary question, because it means that someone might steal our thunder out from under us.  Normally you can push that thought out of your head, but it’s difficult when everyone keeps asking.

“I don’t know,” I say, “Under three months.”

I wish that number was a bit larger.