Evermight

• Works
• Services
• Thoughts
• Contact

Works

• SM

  Start Mission

  Start Mission is our own project management and invoice management web software.  You can use it to manage projects, create task lists, track billable time, craft invoices and record expenses.   Best of all, Start Mission is FREE!

  
• TDC

  Toronto.com

  Evermight works with Torstar Digital on toronto.com, the place to go to find out all things happening in Toronto.   Evermight helped build their finders, microsite platform and integration with ourfaves.com.  

  
• DF

  Donation Farm

  Coming soon...

  
• CUC

  Credit Union Central of Canada

  Evermight works with Credit Union Central of Canada to launch their new credit union locator and mobile website. Working within the strict security constraints of cucentral's IT infrastructure was an interesting challenge.  In the end, we released two quality products worthy of mention in Toronto's Globe and Mail newspaper.

  
• TDF

  The Dashing Fellows

  Coming soon...

  
• SSC

  Speed Skating Canada

  We are proud to support our Canadian athletes in the 2012 Olympics!  To show our enthusiasm, Evermight works with Trojan One to build Speed Skating Canada to inform the world of the talented speed skaters in our country.  This bi-lingual site has up to date news, skater profiles, vast amount of documents and a club locator for more than 200 clubs in Canada!  Go Team Canada!

  

Thoughts

• How to distribute equity among multiple founders

  If there are multiple founders in your business, DO NOT DISTRIBUTE EQUITY EVENLY!

  If there is more than one founder in a business, it is almost always a bad idea to distribute equity evenly among founders. Rather than write about it myself, I will post popular blogs that explain why:

  • Founder's Pie - A method to determine equity distribution
  • Time-based vesting schedule for equity
  • How much equity am I worth?

• Off the shelf vs. build from scratch

  When should I buy off the shelf software solutions for my business?

  Question: When should I use an off-the-shelf solution as opposed to building from scratch?

  The answer is that it depends on what you plan to do.

  To most people, an off-the-shelf solution may appear to be an affordable option since the original author planned to resell the solution at a fraction of the development cost.  But there are limitations to an off-the-shelf solution, with the biggest limitation being the inability to modify/add new functionality.  Generally, the most you can do to customize an off-the-shelf solution is change logos, colors and content.  (One exception is if the off-the-shelf solution is a popular development framework/platform like Wordpress or Drupal, which was meant to be extended via developers.)

  Generally, you can not modify the functionality of an off the shelf solution because:

  1. Purchased solution will have insufficient documentation
  2. High chance existing solution will consist of poor quality code

  A developers spends 80% of his time reading code and 20% of his time writing code.  This reality can best be explained via an analogy.  Imagine you were asked to write chapters 110 to 120 of War & Peace. Before you can write these chapters, you would need to read chapters 1 to chapters 109, to ensure your writing narrates the story with a coherent plot, voice, structure etc...The same is true of a developer writing new code to an off-the-shelf solution.   A developer spends most of his time studying the work of the past developer to make sure his new code works correctly and harmoniously within the greater framework.  This is generally very difficult to do, especially when a software is not properly documented (which is 95% of the times).

  Off-the-shelf solutions are great for proof of concept demonstrations.   They are also great as tools to support the core competency of a business, as opposed to being the core competency of a business.

  If you intend to be a software as a service business, then you should build from scratch using a Minimum Viable Products approach.  Building from scratch costs more, but it also provides the greatest value when executed against a sound business model.

   

• Have a developer assemble your product specifications

  Do not assemble a detailed feature list without the guidance of a technology professional.

  Some clients get so excited about their idea that they prematurely assemble a product specification document or detailed wireframes in the absence of an experienced technology professional (eg. software developer, user experience developer, information architect or product manager). This document immediately becomes irrelevant to everyone, including the author, after a developer reviews it and arrives at any or all of the following conclusions:

   

  1. the feature specifications can not be completed within a reasonable budget
  2. the feature specifications are in conflict with each other
  3. there are too many features most of which will probably never be used
  4. most of the feature specifications do not belong in a beta or in phase 1
  5. the feature specifications conflict with industry best practices on user experience
  6. the feature specifications will not satisfy the client's business objectives

   

  It is very tempting for a client to prematurely engage in product definition and wireframe development because he thinks he is getting a head start with just a pen and paper. But we encourage a client to refrain from doing so because it is often a waste of time (and even counter productive if the client becomes married to his idea) since the client does not have intimate working knowledge of technology and industry best practices.

  Instead, the best thing a client should do to initiate a project with a developer is to outline all the problems his business intends to solve. It may take time to educate a developer on the magnitude of each problem. After doing so, the developer should work together with the client to assemble a reasonable product specifications document that avoids all of the issues mentioned earlier.

  If a client is still tempted to assemble his own product specifications document or wireframes, he should keep them extremely high level and leave it to a developer to fill out the details.

   

• Build the product, boot strap it (aka MVP)

  You are convinced you need to build the product from scratch, but that will cost a lot. What should you do?

  We are convincing our clients to NOT plan too far ahead in development. Just be mindful that software is never finished.   Work on the product one iteration at a time.  Be as small, incremental and agile as possible. Get a product to market asap to get user feedback before deciding to build more features.

  Consider facebook as an example.  It is a monster multi-billion dollar company.  But people forget that the first version of facebook took Zuckerberg just over a month complete.  And despite having a minimal set of features, it became a wild success upon launch.  This is not an anomaly.   Building minimum viable products in just a couple of months is a common practice for successful consumer facing web/mobile technology products.  Develop new features based on user feedback.  This is a popular way to avoid spending capital on features that don't matter.

  Watch this video on the concept of lean start up to better appreciate our point of view.

   

   

• Apple refuses to give a straight answer

  Apple never gives a straight answer on even the most basic of questions.

  I recently asked Apple a question on whether or not I could create a templated app where all I had to do was just change the skins and content for each client I sell this app too.  Will the Apple store reject apps on the basis that they were functionally the same?  If not, which type of Apple Developer license should I get?

  I had about 5 email exchanges (because the App store does not have a telephone number), and they were all ambiguous answers.  They just couldn't give me a simple yes/no answer.  Some things they said,

  "With regards to using the same credit card for multiple different enrollments this is possible although you may run into issues due to the applicant name and billing information not matching."

  WTF?  I "may" run into issues?  Come on now piss brain, you're running the show here.  Just tell me if there will or won't be problems.

  "To answer your question, please review the iOS Developer Program License Agreement details with your own legal counsel."

  Ok dim wad....why do I need a lawyer when you can just give me a simple yes/no answer.

  Ultimately, we did not get an answer from Apple, and I had to get advice from other developers on Linked in. 

  See what other Apple Developers had to say here.

• Apple rejects app that have buttons with rounded corners

  Apple rejected our app because buttons with rounded corners made it look too much like the iPhone environment.

  Apple rejects us again!

  This time, on the dashboard of my app, I had a grid of 3x3 buttons. The buttons were things like Home, About Us, Location, Favourites, News etc... The buttons used the default rounded corners offered by XCode/the cocoa framework, with the addition of a background icon to denote what section the button is for.

  Apple rejected my app because they said the rounded corners on buttons made the dashboard too similar to the iPhone desktop. Of course this infuriated me. So I ended up sharpening the corners of the button, but doing this isn't as simple as something like cornerRadius = 0px.  I discovered that with the rounded corners, you can increase the radius, but not reduce it below the default. That is not programmtically intuitive at all.  I ended up doing something more laborius by re-drawing all my buttons with a Custom Button....that of course $#@$#@ pisses me off.

  Why does the cocoa framework encourage/tempt developers to use round corner buttons if the App store will reject it?  Why does the cocoa framework offer UI elements that are consistent with iOS creative direction even when the App store will not accept it?  Why do they want to #$@#$%#$@ make developer lives a nightmare?

  Not only that, the sharp corners look absolutely ugly.

  Next time, I'm going to parameterize the styles on my button. I'm going to assign the corner radius styles from an xml feed the iPhone app is already reading from. Then submit the app, so that while the reviewer is reviewing hte app, he will see sharp corners. But once the app has been released into the market, I will change my xml feed and tell the app to show rounded corners again.

  Take that Apple! I'll get my rounded corners back!

  You can follow this discussion on LinkedIn.

   

• How much is a business idea worth?

  You have an awesome business idea. But how much is it worth? Is it really a secret?

  In the grand scheme of things, a business idea is worth very little.  It's all about the execution.   Browse the internet for equity distribution in a start up and you'll find typical a break down like this:

  • Idea: 3% - 5% - ideas these days are cheap, everyone is having them its execution that counts.
  • Technical: 15%-35% - all developers (including myself) think its worth more but if you don't have the rest in place then its just a cool thing that sits on the shelf being worthless to everyone. This is what both your shares will be diluted down to to start with.
  • Marketing / Sales: 15% - 30% - This is pretty important, if nobody knows about you, your nowhere ... but put KPIs against it - X new customers / sales in a timeframe.
  • Business: 20% - 30% - The leadership and vision, this is typically one or two people and they will make or break the company on its own, set the direction.

  This equity distribution above was taken from this site here.  This type of profile breakdown is extremely common among web/mobile start ups. The equity distribution can vary via a time-based vesting schedule. In any case, you'll notice that an idea is cheap relative to the execution of the marketing, business and technology.

  Since ideas are cheap, one should spend more time sharing their ideas with others to create new ideas.  I encourage you to watch the video below to appreciate why:

   

  In short, Johnson discovered that great ideas rarely happen instantaneously (the eureka moment), but rather, great ideas fade into view after many years of refinement and merging with other people's ideas. Johnson also discovered that increased levels of innovation generally happen in open collaborative spaces such as coffee houses, conference rooms and laboratories. As such, Johnson argues that people should spend just as much time sharing ideas as they do protecting them (with NDAs, IP, contracts etc...). Additionally, in another video, Matt Ridley explains that closed ideas can be at significant risk to de-evolution.

  Given the benefits of sharing ideas, I often encourage entrepreneurs to share their "general business ideas" so others can offer valuable feedback and/or complimentary ideas. Detailed implementation secrets that required considerable resources to realize should of course be confidential. But since general ideas are cheap, the benefits of sharing them far outweigh the costs.

Contact Us