Eighteen months ago, I left a job that no longer represented me, and started on a self-funded journey to re-imagine working life.  With the help of my close friends, family and community supporters, we launched Zeus River, our small but unforgettable mobile app development business.  It’s been a roller coaster ride to be sure, full of highs and lows that I’ve never seen at a regular job.

As we close out 2012, here are a few things that I’d like to announce in this space:

Goodbye Zeus River, hello People & Code

With the conclusion of this post, I’m moving on to join Ray and Bonnie at People & Code, a full service web and mobile development agency based in Toronto. People & Code was incubated over a period of several months by a coalition of teams, including Zeus River, that were previously working out of The Work Republic. In the new year, we’ll be working out of a new office space at the corner of Queen and Spadina alongside our close friends at Brand Mueller.  While I’m still a co-founder at People & Code, my individual role will evolve into more of an operations analyst and strategy lead.

Cleaning out our blog closet

With our archive of blog posts moving over to the People & Code, this site is redundant and will be deprecated. The brand names have changed, but the story remains the same: an adventurous band of strangers have assembled around a vision to breathe new life into the Toronto digital and creative technology scene. We’ll continue to document our progress on the new People & Code blog.

Here’s to a wonderful 2013!

-Milan

If we learned one lesson at The Work Republic, it was that nothing breeds familiarity like proximity.  Most advertising agencies in Toronto work within a three-block radius, and if you’re serving this market, you must keep yourself in the middle of that noise.

To give you an idea of how much you can expect to pay, I’ve shared a list of office spaces and their accompanying rents in downtown Toronto.  This information has not been kept up-to-date, but it should serve as a decent guide for what to budget.  Not surprisingly, most of office space available is located in either the traditional entertainment district (Richmond/Spadina) or the new Liberty Village district on King St. West.

(FYI I blatantly stole this info from a website that I can no longer find online, but I’ll update the post with a source link if I can track it down)

Update: The information from this post comes from Chris Fyvie (@ChrisFyvie) at officesearchtoronto.com.

In table form:

In map form:

View Downtown Toronto Office Space in a larger map

Download the raw data as a CSV or XML.

I watched an interview recently with an entrepreneur who started a new venture a few months ago.  In the interview, the entrepreneur speaks about how he passed on a six-figure salary with a prestigious Fortune 500 company to work full-time on his idea, and he uses this anecdote to encourage potential technical co-founders to take the same risk that he did.  This type of startup recruiting is misleading, disingenuous and frustrating.

The entrepreneur is the lucky one, not the chosen one

There are a variety of socio-economic factors that contribute to your risk tolerance.  If you’re in a position to forgo a six-figure salary and start a company of your own, you’ve got guts - and you’ve had good fortune.  Don’t kid yourself into believing that your potential technical co-founder is taking the same risk that you are, when they may or may not have been given the same kinds of privileges as you.   There are a precious few that can pursue entrepreneurship, and even fewer that can pursue it full-time.  That’s one of many reasons why most Silicon Valley entrepreneurs are young, white males.

Forgoing a well-paid job is not real work

Hard work, determination, creativity and wisdom cannot be measured by the amount of time you’ve spent or the amount of money you’ve forgone.  But there are tons of ways to build value into your company before you find a technical co-founder, and all of those ideas can be quantified with metrics that prove traction.  If you sell a software developer on anything but those metrics, expect them to turn you down and call you on your bullshit.

Thanks to jmv for the photo.

Update: Discuss this post on Hacker News.

Imagine that you want to buy a home.  Instead of buying an existing home, you decide to build a house.  You are on a tight budget, so instead of hiring a licensed architect, you decide to draw the blueprints yourself.  After months of careful planning and rigorous documentation, you meet with a home builder, place your drawings on her desk and deadpan: ”I’ve already created the blueprints.  I just need someone to lay the bricks.”

What do you think the home builder will tell you?

Everyone’s an architect until the house falls down

A house isn’t constructed until it has gone through a lengthy, rigorous architecture process.  High-quality software operates the same way.  If you want to maximize the value of your investment, you need an engineer to think through many long-term considerations:

• How does the plumbing connect to the sewer? (in software terms: how should memory be allocated and managed throughout the lifecycle of the application)
• How will the electrical wiring be exposed in terms of connecting circuitry? (in software terms: how should your API web service be built to support other applications)
• What combination of materials will maximize the durability of your house? (in software terms: on which software platform(s) will the app be built and maintained?)
• How should traffic optimally flow? (in software terms: how should you optimize app performance during peak load).
• How do you comply with environmental and legal standards? (in software terms: how can you get your app approved by Apple and the communities who will support your promotional efforts)

Many times, some people ignore these considerations and jump straight into wireframes.

UX is architecture, UI is interior design

Wireframes are sort of like interior design; they describe what the colour of the couch is, and where the couch should be located.  These are not the concerns of your architect when you’re building a home, and they are not the concerns of your software developer when he/she is trying to build your app.  If you didn’t involve a developer in your wire-framing process, you’re setting yourself up for a situation in which the couch looks gorgeous in a house that will crumble at any minute [1].

Ray and I now politely decline projects where wireframes are already drawn out.  Your best bet is to find an offshore development team to complete your project.  We’re happy to refer to you to ours.

Notes

[1] For what it’s worth, most home developers hire professional interior design firms to showcase their final constructed product, much like real software developers hire professional UI/UX designers to collaborate.

Update (Nov 4, 2012): Before I hit send on this post, I put a question out to Twitter, asking how others handle this question of wireframes over products.  As expected, Toronto didn’t disappoint me with their responses.

Update #2 (Nov 5, 2012): Discuss this post on Hacker News.

People ask me all the time about tools that we love in the office.  I like to think of a company’s tools as a living extension of their values.  Ray and I have always tried to support tools which are open source, freely available and community powered.  Here are our most commonly used tools:

GitHub.  A clear choice as our source control system.  We use GitHub to track/log/prioritize issues, manage dev milestones, add wiki-style documentation, manage permissions and check out analytics around key operational metrics.  I cannot imagine our life without GitHub.  In a few years, I believe we’ll think of a GitHub account for professional developers the way that we currently think about LinkedIn for other professionals.

Trello. Started as our project management tool, but it’s evolved into a generic “Microsoft Excel” style tool for any list, table or matrix.  Trello allows you to assign, prioritize, crowd-source, label and manage any number of workflows in your organization using the popular Kanban style of process management.  Plus, the founders have committed that it will remain free.

LinkedIn.  I use LinkedIn as a lead generation tool to figure out how I can get introduced to new people.  Most sales people swear by its power.

Pancake.  I know its blasphemous to not use Freshbooks in the city of Toronto, but Pancake is a better value play.  For a one-time fee of $49, you get all of the basic features you need to create, store and track invoices.

This past weekend, I had the pleasure of attending a first in Toronto — Hacking Health Toronto, a 48 hour health-focused hackathon.  Here are some thoughts on the event:

What made Hacking Health awesome

• Palpable excitement: There was a special buzz in the room that you could feel from the moment you walked into the MaRS building on Friday night.  Healthcare providers seemed giddy at the thought of being able to solve their own problems with no limits on their creativity and imagination.  We need that kind of passion and energy in our city in lots of different forms.  That made this event special.
• Integrating design into the hacking process: Traditionally, hackathons are organized for software developers only.  Hacking Health introduced a unique twist where designers were integrated into the early-stage process.
• Real people, not large interests, running the event: The event was run by young, energetic volunteers with no real agenda other than to facilitate the best event possible.  The organizers were given complete creative freedom to put on the event without external influence or undue pressure.  They should be applauded for their efforts.
• Focus on small-scale problems: Hacking Health appears to have been born, at least partly, out of frustration with slow-moving government agencies and projects like eHealth.  I like the idea of a bottom-up, grassroots approach as a counterweight to the current top-down approach.

Suggestions for improvement

• Don’t minimize the software development process: Most hackathons promote the misguided premise that a mobile app can be built and delivered in 24 hours.  In reality, software take months, even years, to deploy correctly.  There are many differences between how you imagine an app and how you ultimately release an app.  When you encourage an approach that minimizes (or even skips) strategy, design, test, support, scale and promotion, the results diminish the development and design work of everyone in the Toronto tech space.  We deserve better than this fate, and we should stand up for ourselves on this topic.
• Encourage more two-way knowledge sharing: There were plenty of health care providers who were subject matter experts, teaching “hackers” about problems in health care. I was disappointed that there weren’t more health care professionals taking an interest in learning about the software development process.  There wasn’t much of an appetite for how to create an MVP, quantify objectives, reduce wasteful iterations and develop user focus.  The health care providers seemed to place too much emphasis on the idea, whereas tech folks tend to see ideas as basically worthless.
• Advocate for quality open data standards: There was one unifying concept that Hacking Health demonstrated for health care providers and tech experts alike: the Canadian healthcare system will not have meaningful technological change until a fully open, freely available, completely transparent data infrastructure is put in place [1].  Almost every pitched software app focused on access to existing patient data, medical information or proprietary knowledge.  Hacking Health missed a valuable opportunity to push for these kinds of standards.

Things you should NOT do at the next Hacking Health event

• Pitch solutions based on false premises: There were several presented solutions that played on the idea that “healthcare in Canada is sick / unsustainable / dying / crumbling”.  This is some combination of false, disingenuous and misleading.  It is largely a myth that the Canadian healthcare system is unsustainable [2].  We should call B.S. on this kind of falsehood.
• Use tragic current events and circular logic to draw attention to your idea: One of the pitches involved the invokation of Amanda Todd’s name to draw attention to how a mobile app could help children learn about mental health.  Call me over-sensitive, but I found this unnecessary.  By all means, use passionate stories to draw in your listener, but avoid tokenizing or manipulating current events to build interest [3].

In the next post, I’ll share my notes from the opening night of 50+ health-tech pitches.

Thanks to the sharpest dressed man in Toronto, Christopher Mudiappahpillai, for the photo above from his Twitter stream.  Also thanks to Ritika Goel for reading drafts of this post.

Notes

[1] To be clear, I am not referring to opening up patient data.  I’m referring to open data standards around patient metadata.  As a software developer, I don’t need to know what info is contained in the “Smith, John” record.  I’m far more interested in the infrastructure that allows me to build “last name, first name” into my application, and then leave it up to John Smith to personally authorize usage of the app.  This is how Facebook, Twitter and various Google apps currently authorize access to your personal data.

[2] Increased healthcare costs have far more to do with powerful special interests (pharmaceutical companies, medical lobbies, private health insurance companies, etc.) than any government bureaucracy or public sector misappropriation.  Sources here, here and here.

[3] I ran this by someone who completely disagreed with my point of view, and felt the reference to Amanda Todd was completely appropriate.  Maybe I’ve got this wrong.  I’m curious to see if others agree or disagree – is there a line that you should not cross when you are making a pitch?

A few days ago, our friends at #LeanCoffeeTO asked the community for Episode #91 topic suggestions.  This got me thinking – I have no idea what has already been discussed!  I went back through the Meetup group, and compiled a list:

• #90 — Managing Customer Relationships
• #89 — Staying Lean Internationally
• #88 — Retention Marketing
• #87 — Marketing to Small Business
• #86 — Lean for Freelancers
• #85 — B2B Marketing
• #84 — Early Stage Marketing and Sales
• #83 — Agile Everything
• #82 — Creating a Marketplace (‘Two-Sided’) Start-Up
• #81 — Going Big in Toronto
• #80 — Effectively Handling Competition
• #79 — Metrics when you’re selling entertainment or games
• #78 — Non-Tech People in Tech Startups
• #77 — Non-Tech People in Tech Startups
• #76 — Actionable metrics from small (beta) groups
• #75 — Launching with Social Media
• #74 — Launch Considerations
• #73 — Pricing Continued
• #72 — Pricing Revisited
• #71 — Lean Methodologies for Mobile
• #70 — Lean Methodologies for Mobile
• #69 — Customer Dev challenges when selling to enterprise
• #68 — Post-Deployment Iterations and Release Cycles
• #67 — Social Media Week Edition
• #66 — Smart Ways to Build Products
• #65 — Beyond the Validation
• #64 — What’s New in Customer Development?
• #64 — Tues Session — What’s New in Customer Dev?
• #63 — Managing a Growing Team
• #62 — Pirate Metrics and Customer Feedback
• #61 — Hackathons
• #60 — TBD
• #59 — GIT Money
• #58 — Lean Canvas vs. NABC
• #57 — Case study: Lean Hypotheses
• #56 — Partnerships
• #55 — Is your messaging clear?
• #54 — Founders
• #53 — One Year Anniversary Week Spectacular
• #52 — Accountability
• #52 — Redux
• #51 — “Ideas are Overrated”
• #50 — Raising Your First Round
• #49 — Customer Types & Business Models
• #49 — Partnerships
• #48 — CaseStudy: Vizualize.me
• #47 — BizDev
• #46 — The Chicken and the Egg
• #45 — Micro Case Studies
• #44 — New [Macro] Trends = New Opportunities
• #43 — Finding Talent
• #42 — B2B vs B2C
• #41 — Entry and Exit Points
• #41 — Startup Entry (and Exit) Points
• #40 — The Mobile App Business
• #39 — Culture as a Competitive Advantage
• #38 — How to Assemble a Board of Advisors
• #37 — Pricing & Estimating
• #36 — Effective Communication
• #35 — Minimum Desirable Product
• #34 — How to actually launch a product
• #33 — Micro-Management
• #33 — Case Study w Ali Asari of Well.ca
• #32 — Product vs. Project Management
• #31 — Lean UX
• #30 — Identifying Customer Segments
• #29 — The Fast and The Focused
• #28 — Get Your Messaging Straight
• #27 — The Problem Interview
• #26 — Problems Worth Solving
• #25 — Metrics
• #24 — Deep Dive into Hiring
• #23 — TBD
• #22 — Side Projects
• #21 — To Document or Not To Document
• #20 — What ‘lean’ really means
• #19 — Case Study: Structuring Experiments
• #18 — Case Study: Howdy Partner: An alternative business model using partnerships.
• #17 — Annual Planning: What are your 2011 goals/vision?
• #16 — Customer Development
• #15 — How to Fail Successfully
• #14 — TBD
• #13 — From “Small L” to “Big L”
• #12 — Process
• #11 — Pricing
• #10 — The Refreshing Lean
• #8 — Finding Talent

If anyone knows what happened in #1-7, feel free to share in the comments section, and I’ll update this post.

I’m going to use this space to clear up issues around how pricing works at Zeus River.  Our pricing is fairly consistent with how most small shops handle software development, so this post should be useful for independent software developers (sellers) as well as potential buyers who are cautious about sticker shock.

Every vendor attempts to maximize price point based on what he/she believes your demand curve is.  You can be sure that once a vendor understands what you are asking for, they will have a good idea of how much you are willing to pay.  If you want to get the best possible price for your mobile app, you must recognize which of these seven buyer categories best describes you:

1. You’re an individual who has an idea, and you want to strike it rich on the App Store.

You don’t want to go through a process of strategy, design, test, support or promotion.  You’ve already drawn out how the app will work and you need someone who can code the screens, interactions and UI elements.  Ideally, this person will not be compensated upfront; they will simply share in the profitability (and risks of failure) that the app generates.

Your best bet in this scenario is to find a freelancer on oDesk or elance.  Unfortunately, between the poor quality of work, and the lack of face-to-face interaction, offshore online development carries the highest risk as a buyer.  Communication is limited, corners are cut and project satisfaction is not guaranteed.  Still, you can’t beat the price…

Price: $1,000 – $5,000

2. You’re an individual who wants to build a demo app / proof of concept to sell an idea to an investor.

You want to pitch an idea to investors or apply for a government grant, but first, you want to build a full-featured prototype.  You need minimal support with strategy.  You’ll handle some portion of the app building yourself.   You aren’t looking to build a completely functional app, and you’re willing to live with no testing, support and update services.

Price: $10,000 – $15,000

3. You’re a firm that wants to build a full-featured mobile app for a marketing solution.

You are a marketer yourself, or you’re a design or ideas firm with a solid UI/UX base, and you want high-quality, hard-to-find development to complement your skill set.  You want to make something entertaining, useful and consumer-focused.  Your ROI is based on metrics like engagement, number of views, followers, etc.  You believe that the right product, coupled with the right amount of buzz, can help your brand.  You have no technical skills, but you’re a gadget freak to the core so you’re already familiar with mobile technologies.

Price: $15,000 – $30,000

4. You’re a firm that wants to build a full-featured mobile app for an enterprise solution.

You intend to make money off the app or its connecting technology.  You want a full team that can provide strategy, design and support for the service.  You have an in-house team of subject matter experts who will provide guidance on industry focus.  The success or failure of the mobile app is your full-time focus.

Price: $30,000 – $50,000

5. You’re a firm that wants to build an enterprise solution with a mobile accessibility component.

You’ve thought about hiring someone full-time on salary to build this solution, but the project is critical enough that you want to use a team of highly trained experts.  You likely want a full-featured web analytics portal so that your administrators can login and view statistics on who, where and how people are using the app.  There may also be integration points to third-party services.

Price: $50,000 – $100,000

6. You’re a firm that wants to build a full-featured video game.

You want to build a high-end game with heavy graphics, 2D animation, built-in support, extensive game dynamics and innovative designs (think Cut The Rope or Angry Birds). If you want to compete with existing publishers in this space, the floor starts very, very high.

Price: $100,000+

7. You’re a firm that wants mobile to be the core of your corporate strategy.

If you’ve reached this point, it makes sense to think about bringing software development in-house.  You want to pay for the developer salary, overheads and training.  A good example of this bucket is Hailo, which recently launched its service in Toronto.  Their team built a mobile app in-house as a critical part of their strategy to disrupt the taxi industry.

Price: $100,000+

Conclusion

Most tech-focused agencies of less than 10 employees use this framework as a rough pricing guide when they sell software development and design services, assuming a 15-25% markup on development costs.  Again, I stress that this is a ROUGH guide.  Companies who rely on offshore development will generally be on the low ends of the scale; companies with brand names and large development teams will generally be on the high ends of the scale.

Thanks to 401K for the photo above.

If you follow the startup scene in Toronto, you’ll begin to notice a pattern amongst most successful high-tech startups.  There are usually two roles that are required to be a founder, but contrary to popular belief, neither role necessitates having technical skills.

The two important roles are:

1.  The Vision Founder (the “CEO”)

• Responsible for cash flow (either from customers, clients or investors)
• Builds relationships and acts as the external face of the company
• Focuses on how to build value into the brand
• Key traits: charismatic, competitive, outgoing, efficient

2. The Day-to-Day Founder (the “COO”)

• Responsible for day-to-day operations
• Depending on the size of the vision, this role can be split into two different duties – technical and operations
• Focuses on how to maximize organizational value (i.e. maximizing cost-effectiveness, building innovative process, acting as a subject matter expert, setting cultural tone, etc.)
• Acts as the internal face of the company
• Key traits: analytical, competitive, outgoing, efficient (notice the similarities to the first founder!)

A few examples to illustrate the pattern

Toronto-based companies with only a CEO and a COO: Jet Cooper (Satish, Verne), Wave Accounting (Kirk, James), Rypple (Dan, David), 500px (Oleg, Evgeny)

Toronto-based companies with a CEO, COO and a CTO: BNotions (Alkarim, Mark, Logan), Freshbooks (Mike, Levi and Joe), Shopcastr (Matt, Judy and Aaron)

Technical co-founders do not exist

You’ll notice that the day-to-day co-founder may or may not be the technical co-founder.  In some cases, this is true. But the reality is, founders are capitalists.  They can double as workers in a pinch, but they cannot be workers exclusively.

Workers are terrible co-founders.  They love to work.  They don’t love to maximize value out of other people’s work.

When you try to find a coder or a designer who focuses exclusively on technical skills, you’ve already lost.  You don’t need a technical co-founder to start a company, and you certainly don’t need one to start an agency.  It is far more important to have two founders that are involved full-time, believe in the company mission and trust each other to carry out independent roles.

In other words, the hardest part of starting a business isn’t accumulating skills, but sharing a vision.  Next time you’re at a Sprouter event, spend less time looking for someone who can build your idea, and spend more time finding someone who is willing to quit their full-time job to work on an idea you both believe in.