It's been ~2 years since I founded ForecastOS and ~12 years since I started my investment banking -> software engineering -> quantitative investing -> founder arc.

I’ve learned a lot the hard way (pain) and the easy way (patterns).

Below is a collection of 12 principles I keep coming back to. Take what’s helpful. Ignore the rest.

1. Expect Everyone to Act In Their Own Self Interest and You'll Rarely Be Surprised
2. Once Something Is Agreed, Paper it Immediately
3. Don't Deviate Far From Standard Terms
4. Be A Good Steward of Capital
5. Beware The Most Dangerous Person in the Room
6. Improve Health to Improve Productivity
7. What Product-Market Fit Feels Like
8. (How to) Hire Extraordinary Employees
9. Avoid Complexity
10. There Can Only Be One (Founder & CEO)
11. Know Your Odds of Success. Be Good Enough To Succeed
12. The Central Limit Theorem of Advice

1. Expect Everyone to Act In Their Own Self Interest and You'll Rarely Be Surprised

A nicer way to say this is: “show me the incentive and I’ll show you the outcome.”

People aren’t evil. They’re incentivized. And incentives beat values more often than we’d like to admit, especially when money, ego, status, or job security are involved.

Don’t rely on other people to be saints.

Instead:

• Assume self-interest. If someone benefits from doing something that disadvantages you, expect them to consider doing it.
• Design for it. Make it in peoples’ best interest to do what you want, and not in their best interest to do what you don’t want.

This applies everywhere, including:

A) Employees / ESOPs

Retain and motivate employees by structuring comp and equity such that staying and performing is rational (i.e. better than what is available to them elsewhere). Don’t rely on loyalty. Loyalty can be fragile when rent is due.

B) Customers / Vendor Risk

No one gets fired for buying from Salesforce. People do get fired (or look dumb) for betting their roadmap on a startup that disappears in 18 months.

If you’re early-stage, you’re selling against risk, not just features. You can reduce that risk by:

• selling to smaller / risk-tolerant customers first,
• selling something low-effort to adopt (i.e. low switching cost), or
• building something new (i.e. not available elsewhere) or 10x better so that the buyer can justify the risk.

C) Investors / Partners / Advisors

Always ask: what do they want? How does my success (or failure) affect them? Once you see their incentive clearly, advice becomes easier to evaluate.

2. Once Something Is Agreed, Paper it Immediately

I’ve regretted not doing this more than once; I was slower than I should have been to learn this lesson.

A surprising number of people will change spoken commitments after the fact - sometimes without highlighting changes. Putting something in writing doesn’t “ruin the vibe.” If they’re serious about their verbal commitment, nothing changes.

Paper it. Immediately. And validate all details are as agreed.

3. Don't Deviate Far From Standard Terms

Weird terms create weird problems later.

If your salaries, equity grants, board rights, valuation, customer contracts, or investor terms are too far from normal ranges, future employees / customers / investors will ask: “why is this weird?”

Find out what typical bounds look like. Pick a sensible spot in that range. Save your novelty for your product / solution.

4. Be A Good Steward of Capital

Won’t someone think of the shareholders?

If you raised money, that’s shareholder money, not your money. Treat it with respect. Protect it. Try to grow it. Cut waste aggressively.

You should be proud to show investors each line item on your income statement:

• “Look what we built.”
• “Look how little we spent doing it.”
• “Look how capital-efficient we were.”

Keep offices austere. Revisit spend constantly. If you’re technical, find technical deals: negotiate vendors, use spot instances where possible (often 70% savings), avoid shiny tooling that doesn’t move the needle, etc.

We wouldn't have survived long enough to build a successful product (Hivemind was our fourth product) if we weren't so careful with our finances.

In startups, survival is compounding. The longer you survive, the longer you have to find product-market fit, and the more likely you are to produce returns for shareholders. It's all about the shareholders.

5. Beware The Most Dangerous Person in the Room

Watch out for people in (senior) roles who don't deserve them on paper. They have the most to lose.

My experience has been they (by necessity) prioritize politics, posturing, and narrative management over outcomes. Expect them to behave accordingly.

You can sometimes spot them by:

• unimpressive schooling / grades in fields where it matters,
• unimpressive experience,
• exaggerated achievements,
• shallow understanding of (and network in) the problem space,
• a pattern of conflict (e.g. public lawsuits, accusations),
• etc.

Avoid working with them if possible, despite charisma and assurances. Remember: where there’s smoke, there’s fire.

6. Improve Health to Improve Productivity

The healthier you are, the higher your average speed. Being healthy isn’t just self-care; it’s throughput. As such:

• sleep +8 hours whenever possible,
• do cardio and lift weights - a little goes a long way, and
• work <=60 hours a week (hands on keyboard).

As a former investment banking analyst, I can confidently say the following about +60 hour work weeks:

• outside of doing god's work (i.e. rearranging logos in PowerPoint at 4 AM for a 9 AM meeting), they are not needed / productive,
• your health (and output) will slowly degrade, and
• your marginal hourly productivity will become negative. You aren't well enough rested to be clever.

Every successful founder I know doesn't sustainably work more than 60 hours a week (hands on keyboard).

Work (sustainably) hard. Exercise. Rest.

It's a marathon, not a sprint.

7. What Product-Market Fit (PMF) Feels Like

Product-market fit is not a dashboard metric. It’s a feeling. It’s the moment selling flips from actively pushing your product to having it pulled from you.

• You don't sell the product, you describe it / demo it. Buyers want it based on that alone.
• Buyers don't need to be educated. They are aware they have the problem you are solving and are actively trying to solve it.
• Buyers want to talk to you. Most schedule additional calls. Inbound interest picks up substantially.

To find PMF, find a painful, resourced problem.

The best problems are:

• common in a specific niche,
• valuable to solve,
• known by customers; budget exists to solve it, and
• currently solved badly.

Solve that. Sell that.

Listen to problems. Ignore proposed solutions.

Customers are excellent at describing their problems but (often) bad at designing solutions.

As the old adage goes: to travel large distances quickly, people will ask for a faster horse, but what they need is a car.

You can only do one thing well.

That doesn’t mean only try one thing. Try many things quickly. But once something hits (you'll feel the pull), focus on that.

8. (How to) Hire Extraordinary Employees

I have a lot to say about identifying and hiring top talent... BUT I think one heuristic that captures 80% of what is important is: extraordinary people do extraordinary things.

When looking to hire extraordinary employees, look for people with extraordinary accomplishments or achievements. That could be academic, athletic, or professional. Often achievement is not isolated, but repeated, and easy to identify.

Don't expect people without extraordinary achievements to do extraordinary things. While there are (many) exceptions, if they haven't produced extraordinary achievements by the time you are interviewing them, why would they start now? Answer: they probably won't.

With the above in mind, a few other things to be mindful of when hiring:

• Do you like them? You'll be spending +40 hours a week, every week, with them.
• Do they want the job you are hiring for? If they don't, save the time you'll spend convincing / motivating them and find someone who does.
• Do they have the right attitude and aptitude? Everything else can be taught.

9. Avoid Complexity

You can only load so much context into a brain (or LLM, it turns out).

Complexity is a tax:

• harder to understand,
• harder to debug,
• harder to onboard,
• harder to improve, and
• easier to break.

Simple is clever. Clever scales.

10. There Can Only Be One (Founder & CEO)

Elon, Gates, Zuck, etc. With very few exceptions, successful companies (and governments) have one person at the top.

Co-founders are great; they work hard for less cash (and more equity), provide continuity should other co-founders burn out, etc.

But decision-making authority and clarity matter. If you have co-founders, decide who has final say. They become your company's benevolent dictator - the CEO. They become accountable for all top level decisions. They also become the shareholders' one throat to choke.

11. Know Your Odds of Success. Be Good Enough To Succeed

In university level calculus - before grade inflation, smh at you Gen Z - perhaps 50% of the class would fail the final. No one, and I mean no one, thought any of the top math students would be among the 50% that failed. And they never were. They were consistently at the top.

Startups are similar. Maybe 10% succeed. And it’s often the top 10% of founders (and teams) that do.

Anecdotally, all of the most impressive entrepreneurs I know (who were also top decile in academics and work ethic) have succeeded. More or less everyone else failed, perhaps predictably.

Further, in business, like in Catan, they are many winning strategies. The best strategy for you depends on i) what you're top 10% at executing and ii) how the board is set.

The uncomfortable takeaway: avoid games you are unlikely to win. Be honest about what you’re top-tier at, and choose a game where that actually matters.

Two more practical angles below.

A) Know What Success Requires: My Experience Biking Across the Country

When I biked across the country, I did napkin math on what success demanded: km/day, watts/hr, calories consumed, changes in wind resistance and power requirements due to elevation and headwinds (I went Toronto to Vancouver, into the wind), etc.

I did the math on what was needed. Then I trained until my fitness could meet or exceed that.

Companies are multivariate (i.e. many things matter), but the principle holds. Identify the 5-20 variables that actually determine your outcome (ROI, distribution, conversion, retention, product milestones, iteration velocity, hiring, etc.), measure them, then make sure you meet or exceed what's needed.

Easy in theory, hard in practice. But a helpful exercise nevertheless.

B) Persistence Increases Odds of Success

“Never give up” is not a strategy. But persistence plus learning is powerful. Survival buys you attempts. Attempts buy you luck. Luck buys you outcomes.

12. The Central Limit Theorem of Advice

Repeated advice is good advice.

Everyone is searching for the secret insight they’re missing. In practice, you’ve probably already heard the advice you need - multiple times.

Pay attention to what you hear most often. That’s the signal.

Consider the above an n=1 sample from an infinite number of viewpoints on principles for your career / business.

Take what’s helpful. Ignore the rest.

Remember: these thoughts are worth what you paid for them ;)

It's been a while since my last personal newsletter.

Today, I'm excited to update you on:

1. The status of ForecastOS (which I founded a year ago)
2. How I'm avoiding getting fat in my 30s
3. What we're considering for our next car
4. Embracing my founder personality traits

1. The status of ForecastOS

I founded ForecastOS in September 2023.

The goal of the company remains largely the same: providing data and software solutions to institutional investors and finance professionals. Our offering is a mix of open-source software, financial SaaS (Software as a Service), and data as a service.

Our goal continues to be to build quant-first offerings otherwise similar to the giants in the space, like Bloomberg, FactSet, MSCI, S&P Global, and/or LSEG. It would be an understatement to say that we still have a lot of work to do!

But despite being a small team of 2, we've made good progress in the past year:

A) Our annualized run-rate revenue is over C$200,000, admittedly ahead of where we hoped to be in Q4, and over 10x where we were a year prior.

B) We're ready to kick off a Q1 2025 seed round fundraising process to help us grow the team to 5 to accelerate sales, product, and dataset development.

C) We've reached several meaningful milestones:

• Our investment system of record application (we call it Skylight) is ready for institutional use
• We've made +1000 features for ML-driven financial forecasts available. They can be consumed anywhere in 1 line of code through ForecastOS FeatureHub
• We've advanced our open-source portfolio engineering and backtesting framework InvestOS
• We've created a couple proprietary financial datasets that we're testing for alpha
• We've developed a process to price / value datasets
• We've released a ~13 minute demo building and backtesting an ML-powered market and factor neutral quantitative investment strategy using ForecastOS FeatureHub and InvestOS; what used to take an institutional team a full year now takes minutes!

With the above said, there couldn't be more left to do.

If you know anyone who can help build the next great software and data company for institutional investors and finance professionals - a systematic institutional investor, savvy VC, or quant finance engineer - please let me know!

2. How I'm avoiding getting fat in my 30s

If you've visited my wife and I in BC, you probably know that we have a garage gym. Because of this, I was reluctant to join a gym near our office in Vancouver (despite packing on some wedding-season lbs).

That was a mistake that I have since corrected. I found a great $60 / month gym downtown that's never busy at lunch. I'd tell you, but then it might get busy... so you'll just have to take my word for it.

I'm not sure there is a better way to reinvigorate yourself than a quick lunch workout. I wish I could be an early morning person and work out at 6:00 AM everyday (which I've done with moderate success for various stretches of time), but that habit never seemed to stick for me. Lunch time workouts, however, are easy to stick to.

A quick note: I can't explain why, and I haven't deeply investigated this, but lifting weights meaningfully reduces my stress levels. Picking up heavy things calms the mind in a way that cardio doesn't. Much like cardio gives me energy that lifting weights doesn't.

3. What we're considering for our next car

For the last several years I've been interested in road fatality statistics in relation to the cars people choose to drive.

The data I've seen suggests you're an order of magnitude less likely to die in a midsize luxury SUV vs a common compact car, although there might be some selection bias at play.

To me, it seems sensible to chose to drive a car that meaningfully reduces your chance of early fatality. Heavy cars generally do that, albeit while increasing risk for other road users. Given this, it seems odd that car manufacturers like Rivian are allowed to release +6000 lbs EVs to the masses!

All this is to say: our next car will likely be a Volvo :)

4. Embracing my founder personality traits

I've always (I think rightfully) thought of founders as:

• difficult,
• stubborn,
• machiavellian, and
• ruthless.

However, when the aforementioned bad traits are mixed with:

• obsessive work ethic,
• competitiveness,
• skill / creativity / curiosity / insight (developed from years of relevant work and exploration),
• long-term orientation,
• honesty, and
• a sense of justice,

you have the makings of a great founder.

My experience has been that you rarely find successful founders without both the good and bad traits I've listed above. Further, I think some of the bad founder traits are just as necessary as the good founder traits.

Without some of the bad traits, it's too easy to be pushed off the ball. If you aren't at least a little stubborn or machiavellian, you're more likely to accept the status quo and/or undersell yourself, both of which are behaviours that are unlikely to lead to success.

Similarly, founders with few of the good traits seem to flame out around seed / series A; it's hard to build a successful business if you don't deeply understand the problem space, aren't deeply committed, and aren't deeply respected by your staff.

All this is to say: I seem to have some of the bad founder traits. I've spent my life working around them, managing them, and apologizing for them. And to be clear, I think people with those traits should cultivate the ability to manage them; if you can't control your behaviour, it controls you.

Fortunately, I seem to also have the good founder traits. And as a founder, I'm finally accepting both the good and bad traits as part of who I am and who I need to be.

I feel fortunate to be in a role where I get the chance to be myself. To put my good and bad traits to work for fun and profit.

It feels natural.

Until next time - your friend in Vancouver,

Charlie

Hey y'all!

The middle half of 2023 has been busy! I've been fortunate to spend a lot of time in Toronto over the last several months, which has been a treat; I've been able to see many of you!

As is becoming the norm with my email updates, I have 3 fun things to share from the last 6 months:

1. Building ForecastOS and InvestOS
2. Getting married
3. Riding Lord of the Squirrels

1. Building ForecastOS and InvestOS

It has been a poorly kept secret for the last 5 months that I've been working with Delphia and Oracle Alpha to create and spin out a new software company.

On day 1, the idea was to create a portfolio optimization and backtesting solution for quantitative investors. It has since evolved into two offerings:

• ForecastOS, our SaaS solution for simplifying and managing financial forecasting / AI
• InvestOS, our open-source, extensible portfolio optimization and backtesting solution, which integrates with ForecastOS

So what are they, in more detail?

ForecastOS allows anyone, even non technical executives, to understand, analyze, audit, backtest, and (dare I say) manage their financial forecasts through a friendly UI without changing their current solution at all; it plugs into existing financial machine learning pipelines and ties datasets, features, forecasts, and portfolio optimizations / backtests together.

The result is more collaboration, more predictive ideas, better forecast performance, better understanding of and willingness to take risk / deploy capital, and easier to manage AI.

InvestOS, on the other hand, is an open-source (i.e. free) Python module for portfolio optimization and backtesting. It integrates with ForecastOS, but exists independently.

I'll spare you further details and possible (likely?) boredom... but if your eyes didn't just glaze over and roll into the back of your head, or if finance is your thing, I invite you to follow and subscribe to weekly updates on the ForecastOS journey!

2. Getting married

On April 21, 2023, I got married to Jacqueline, the love of my life, at the top of Grouse Mountain, overlooking Vancouver.

They say a picture is worth a thousand words, so here are a few of my favourites:

3. Riding Lord of the Squirrels

There always has to be a biking update. It's a law of the universe. I wish it wasn't so.

Several weeks ago I rode the famous Mount Sproatt trail Lord of the Squirrels for the first time! In between leg-numbing climbing and descending, I captured some beautiful pictures and video. Check them out below!

Until next time!

Your friend in Vancouver,

Charlie

I've missed writing as a creative medium, and as a way to share updates and research. I hope to share more with you all - friends, family, and likeminded individuals on the internet - going forward!

Updates:

1. My GoPro footage from racing in the Norco Canadian Enduro Series (NCES) on Vancouver Island
2. A cursory review of the progress made to date at Founderpath from an analytics perspective
3. Jacqueline and I are getting married April 2023 (for those of you who don't know)!

1. Racing in the Norco Canadian Enduro Series on Vancouver Island

Since moving to the west coast of Canada (and settling down in Vancouver / Port Moody), I've gotten (really) into mountain biking. So into it, that a couple buddies and I entered a Cumberland / Mt Washington 2-day enduro race.

It was an exciting, humbling experience. I came almost last  ¯\_(ツ)_/¯

You can check out a video of the first day of racing here: https://youtu.be/vdark-I8HzQ. My favourite stage (to ride and watch) was stage 4.

2. Analytics Progress at Founderpath

When I moved to BC, I unfortunately wasn't able to keep my quant finance job at CPP Investments. Fortunately, I found a great opportunity at Founderpath as the Head of Strategy (although [random-senior-title] of Quant Finance / Data Science is probably a more apt description). Founderpath provides recurring revenue advances to SaaS companies (often with $200k - $20MM ARR).

It has been 10 months since I joined. Since joining, I've spent most of my time A) creating a distributed data pipeline, and B) forecasting mostly credit-related ML outcomes for SaaS companies.

The aforementioned pipeline is now serving (via API) almost all of the data used, consumed, and displayed by the Founderpath app - for thousands of private SaaS companies! Further, since implementation, the accuracy of our analytics tools has drastically increased, and the amount of time it takes to ingest and prepare new users' data has drastically decreased!

Now that our data is cleaner and more accurate, I'll be able to continue iterating on research to better forecast default events / credit risk - of which great progress has been made to date!

3. Jacqueline and I Are Getting Married April 2023

Saving the best for last: for those of you who don't know, Jacqueline said "Yes" in August of 2021!!! We couldn't be more excited to be getting married in April 2023 at the top of Grouse Mountain 😊

From August 7 to 28 (2021), I biked 4,447km from Toronto to Vancouver to raise money for The Canadian Cancer Society and The Jonny Kellock Foundation. The journey was in memory of all Canadian cancer victims, like my dear friend Jonny Kellock.

This article includes:

1. Ride itinerary (with links to Strava activities)
2. Where I shared updates
3. A note / thank you from me (written after the final ride)

Ride Itinerary

Ride 1 (Aug 7): Toronto > Tobermory (338km)

Ride 2: Tobermory > Ferry to South Baymouth > Thessalon (264km)

Ride 3: Thessalon > Michipicoten (303km)

Ride 4: Michipicoten > Terrace Bay (259km)

Ride 5: Terrace Bay > Thunder Bay (201km)

Day off 1 (Aug 12): in Thunder Bay

Rides 1 to 5: 1,365km

Ride 6: Thunder Bay > Ignace (237km)

Ride 7: Ignace > Kenora (242km)

Ride 8: Kenora > Elie | part A and part B (257km)

Ride 9: Elie > Virden (240km)

Ride 10: Virden > Regina (280km)

Day off 2 (Aug 18): in Regina

Rides 6 to 10: 1,256km

Ride 11: Regina > Swift Current (245km)

Ride 12: Swift Current > Medicine Hat (221km)

Ride 13: Medicine Hat > Strathmore | part A and part B (246km)

Ride 14: Strathmore > Banff (186km)

Day off 3 (Aug 23): in Banff

Rides 11 to 14: 898km

Ride 15: Banff > Rogers Pass (232km)

Ride 16: Rogers Pass > Shuswap (210km; forest fire smoke ended ride a little early)

Ride 17: Kamloops > Boston Bar and forest fire make-up laps (258km)

Ride 18 (Aug 27): Boston Bar > Vancouver (227km)

Rides 15 to 18: 927km

Where I Shared Updates

• Strava: for activity stats from daily rides
• Instagram: for pictures and videos from daily rides

A Note / Thank You From Me

We made it! Toronto to Vancouver. 4,447 kilometres cycled over 3 weeks.

I cannot think of a more intense way to celebrate Jonny, and explore the mountains he loved to surround himself with, than this journey.

Jonny was an adventurous, accomplished (yet humble), hard-working, and light-hearted person. I miss having him around, cracking jokes, and sharing a laugh. I know many of you do too.

To everyone who donated in his memory, joined me for part of the ride, provided encouragement, and shared the journey: thank you, thank you, thank you. As of today, over $29,000 has been donated to the Jonny Kellock Foundation and the Canadian Cancer Society.

A special thanks to 1) my fiancé Jacqueline, 2) the Kellock family, and 3) the Jonny Kellock Foundation. Your encouragement, advice, and assistance made the Journey For Jonny possible. Without you, it would not have been.

Thank you all <3

This article contains a list of the top 50 YC software startups (sourced from the October 2019 YC Top Companies page). It also contains aggregated statistics for valuations and back-end programming languages used.

Values in this article are sourced, but I cannot guarantee their accuracy.

Find me on Twitter @charlieinthe6. View article comments on HackerNews.

Table of Contents:

1. Top 50 Software Startups
2. Aggregated Stats

1. Top 50 Software Startups:

Notes:

• Ginkgo Bioworks, Boom Supersonic, Grin, Memebox, Helion Energy, North, RelativitySpace, and The Athletic were excluded from the below list; I didn't feel they were primarily software businesses. Feel free to disagree with my judgement.
• Values current as of August 15, 2020.
• If one language was the primary language used to build the initial product, one language is listed above. If it was not clear which language was primary, multiple languages are listed above.
• If I couldn't find which language was used to build the startup initially, I referenced the oldest job posting I could find.
• Valuations are approximate and predominantly sourced from recent articles online. Where I couldn't find an indication of value, ~$150M is assumed; startups listed above were all worth +$150M as of October 2019, as per the YC Top Companies page.
• "Y" and "N" values in the "DataSci / LowLv" column describe a startup's primary product (i.e. ML startups would have a "Y" for DataSci). It was included to provide additional colour on why initial back-end language(s) may have been used / selected. The values in this column are based entirely on my own judgement. Feel free to disagree with them or ignore them.
• Ruby and ruby on rails was a popular choice for YC startups around 2010 - 2012. Anecdotally, ~40% of YC startups used ruby during its peak popularity.

2. Aggregated Stats:

Startups with one (initial) primary back-end language:

Startups with multiple (initial) primary back-end languages:

Note: "Startups with multiple (initial) primary back-end languages" table doesn't add to 100% because multiple languages were used for startups.

All startups:

Note: "All startups" table doesn't add to 100% because multiple languages were used for some startups.

I recently started a podcast with my friend Tom Zaragoza called the DEVpreneur. It's a podcast about working on a software / SaaS business as a software developer.

Below I'll explain both how and why you should host your own podcast, as well as potential drawbacks of doing so.

Table of contents:

1. How to host your own podcast
2. Why you should host your own podcast
3. Drawbacks of hosting your own podcast
4. Ending thoughts

How to host your own podcast

In order to host your own podcast, you need to do three things:

i. Add a valid RSS feed to your website
ii. Add the media (e.g. mp3) file to your website
iii. Add the RSS feed to various podcast platforms

Add a valid RSS feed to your website

If your website isn't built using something like WordPress (i.e. you coded it yourself), or you simply want to build an RSS feed for your podcast manually, then you need to create of a valid RSS feed. Apple provides a sample RSS feed as well as documentation on different required RSS feed fields to help you create your own feed.

The XML / RSS feed for the DEVpreneur podcast looks like this.

After you've created your own feed, you can validate it using the Podbase podcast validator. Remember that as you add new episodes to your podcast, you will have to update your feed (or write code that updates your feed for you automatically).

Add the media (e.g. mp3) file to your website

The RSS feed you add to your website must contain URLs that link podcast episodes to their associated media (e.g. mp3) files. As such, you need to upload media files to a publicly accessible location.

You have many choices for where you host your media files. For DEVpreneur, we host the files on charliereese.ca (the same server that hosts our RSS feed) under the /podcasts route (e.g. https://charliereese.ca/podcasts/ep_01.mp3). You could, however, use one of the many cloud storage providers - as long as the file has a publicly accessible route.

Add the RSS feed to various podcast platforms

After you finish creating a podcast RSS feed and have hosted your media file(s) in a publicly accessible place, it's time to add your podcast's RSS feed to various platforms so that it can be found by future listeners!

Which platforms you add your podcast to is a matter of preference, but you may want to check out the following to get started!

Podcast platforms:

• Apple Podcasts
• Google Podcasts
• Stitcher
• TuneIn
• Blubrry
• Spotify

Why you should host your own podcast

At this point you might be thinking, why go through the above trouble to host my podcast when I can pay a nominal fee to have a hosting provider (like Transistor.fm) do it for me? That's a fair question, and there is one reason (other than nerd clout) why you may wish to do so: control.

You retain full control / customization of your RSS feed if you host your own podcast; it's easy to add specific XML tags to your RSS feed if you host it yourself - it may not be possible if you use a hosting provider.

Drawbacks of hosting your own podcast

Hosting your podcast isn't without drawbacks, however.

Every time someone downloads your podcast, a large media file has to be sent from your server (or cloud file storage provider). This could cause problems if you're expecting a very large audience to build over a short period of time, or if you have little bandwidth on the server hosting it.

Further, hosting your own RSS feed and media files will almost certainly take more time to set up initially than using a podcast hosting provider, and your feed may also be more brittle / error prone as a result.

Ending thoughts

While hosting your own podcast is both relatively simple and beneficial, it may not be worth it if you're concerned about setup time, stability, or bandwidth.

Do you host your own podcast RSS feed, or are you planning to? Why or why not? Let me know @charlieinthe6!

This article covers how to use ngrok to easily share a public URL that connects to your local web server (which may be running a website or application that you are developing). This is a great way to test and develop webhook endpoints, or share web applications that are under development, all without having to deploy your code!

This article is broken down into the following steps:

1. Installing ngrok
2. Creating a secure introspectable tunnel to localhost (i.e. creating a URL to share your local web server)
3. Accessing a web application running on localhost
4. Using the ngrok dashboard to replay requests

1. Installing Ngrok

Installing ngrok is incredibly simple:

• Create a free ngrok account
• Download ngrok
• Unzip ngrok (Mac users can unzip ngrok by simply double clicking it in their downloads folder)
• Move the unzipped ngrok binary into your path (so you can call ngrok). Command for Mac users: mv ~/Downloads/ngrok /usr/local/bin
• Your ngrok binary may be in a different location than mine, so you may have to run a slightly different command than listed above
• Connect to your ngrok account by running the ngrok auth command in your terminal found here
• It should look something like ngrok authtoken abc123...

After completing the above steps, you are ready to begin creating instant, secure URLs to your localhost server! Time for step 2.

2. Creating a Secure Introspectable Tunnel to Localhost

Now that you've moved the ngrok binary into your path, you can start using it! To create a tunnel to your localhost server on port 3000, you can run the following:

ngrok http 3000

3. Accessing a Web Application Running on Localhost

The previous command you ran, ngrok http 3000, will output something like this:

ngrok by @inconshreveable                                                           (Ctrl+C to quit)

Session Status                online
Account                       YOUR@EMAIL (Plan: Free)
Version                       YOUR.VERS.ION
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://e123fe.ngrok.io -> http://localhost:3000
Forwarding                    https://e123fe.ngrok.io -> http://localhost:3000

You will be able to access whatever you are running on localhost:3000 through the URL that follows Forwarding above! That means you can share the URL with colleagues in different locations, and they will also be able to access what you are running locally!

4. Using the Ngrok Dashboard to Replay Requests

Using the Web Interface, which by default runs at localhost:4040, you are able to view information for all requests and responses. You are also able to replay previous requests as many times as desired; replaying previous requests is very helpful when debugging or developing webhook endpoints (for services like Twilio)!

And there you have it! Ngrok is easy to install and use, and it's a great way to make what you're running locally temporarily available to the world!

Note: don't forget to be mindful of security when using ngrok

You're here because your rails app is slow, and you either suspect or discovered it has n+1 queries causing performance issues. I've been there.

This article discusses what causes n+1 queries. It also covers 3 tips specific to rails apps for:

• How you can identify n+1 queries by checking your terminal output or by using the bullet gem
• Avoiding n+1 queries by eager loading associations (i.e. load all associations once instead of n+1 times)
• Avoiding n+1 queries by using .size instead of .count

Table of contents:

• What causes n+1 queries
• How you can identify n+1 queries
• How to eager load associations
• Using .size instead of .count

What causes n+1 queries?

N+1 queries are caused by code that loads children of a parent-child relationship (children are the many in a “one-to-many” association). Since most ORMs have lazy loading enabled by default, queries must be issued for the parent record (1 query), and for each child record (n queries).

Said another way, instead of loading all parent and child records at once, n+1 queries loads each record separately.

How you can identify n+1 queries

A. In your terminal:

If you are running your rails application in a local development environment, watch your terminal as your run the controller action (possibly by loading a web app page in your browser) you suspect causes n+1 queries.

Look out for terminal output that looks like the below:

...
Contact Load (1.1ms)  SELECT "contacts".* FROM "contacts" INNER JOIN "contacts_messages" ON "contacts"."id" = "contacts_messages"."contact_id" WHERE "contacts_messages"."message_id" = ? ORDER BY "contacts"."id" ASC LIMIT ?  [["message_id", 4], ["LIMIT", 1]]
  ↳ app/views/messages/_message.html.erb:4
...
Contact Load (0.1ms)  SELECT "contacts".* FROM "contacts" INNER JOIN "contacts_messages" ON "contacts"."id" = "contacts_messages"."contact_id" WHERE "contacts_messages"."message_id" = ? ORDER BY "contacts"."id" ASC LIMIT ?  [["message_id", 5], ["LIMIT", 1]]
  ↳ app/views/messages/_message.html.erb:4
...
Contact Load (0.2ms)  SELECT "contacts".* FROM "contacts" INNER JOIN "contacts_messages" ON "contacts"."id" = "contacts_messages"."contact_id" WHERE "contacts_messages"."message_id" = ? ORDER BY "contacts"."id" ASC LIMIT ?  [["message_id", 6], ["LIMIT", 1]]
  ↳ app/views/messages/_message.html.erb:4
...

As you can see above, a query is being made for Contact records (which have not been cached) multiple times. In the above instance, the contact records were children of a parent record, and they weren't eager loaded (more on eager loading below), causing queries for each child record to occur.

B. Using the bullet gem:

Bullet is designed to help you increase your application's performance by reducing queries made; it catches query performance issues in your code. It will watch your queries while you develop and notify you when you should add eager loading to avoid N+1 queries, when you're using eager loading that isn't needed, and when you should use counter cache.

If you decide to use it (which I recommend you do), use bullet in test, development, or another non-production mode.

I personally have configured bullet for development and testing; if BULLET=true rails test is run, my tests fail for n+1s, unused_eager_loading, and counter_cache. My bullet configuration is as follows:

Gemfile:

group :development, :test do
  gem 'bullet'
end

config/environments/development.rb:

config.after_initialize do
  Bullet.enable = true
  Bullet.rails_logger = true # logs violations
  Bullet.add_footer = true # adds footer to view with violation
end

config/environments/test.rb:

if ENV['BULLET']
  config.after_initialize do
    Bullet.enable = true
    Bullet.bullet_logger = true
    Bullet.raise = true # raise an error if n+1 query occurs
  end
end

Appended to or required in test/test_helper.rb:

if ENV['BULLET']
  module MiniTestWithBullet
    def before_setup
      Bullet.start_request
      super if defined?(super)
    end

    def after_teardown
      super if defined?(super)
      Bullet.end_request
    end
  end

  class ActiveSupport::TestCase
    include MiniTestWithBullet
  end
end

How to eager load associations

You can avoid most n+1 queries in rails by simply eager loading associations. Eager loading allows you to load all of your associations (parent and children) once instead of n+1 times (which often happens with lazy loading, rails' default).

To eager load associations in rails, use the .includes method:

Message.includes(:contacts)
  .order(:scheduled_time)

# or

Blog.includes(articles: [{ comments: :guest }, :tags])
  .find(1)

As seen above, .includes allows nested association eager loading!

Using .size instead of .count

When calculating the number of child associations that exist, use .size instead of .count to avoid n+1 queries in rails.

Why?

When .count is called on an ActiveRecord::Relation, it executes a COUNT query on the database. .size, on the other hand, will call the .length method on an ActiveRecord::Relation if it is loaded (if it isn't loaded, it will call .count). See for yourself in the source code:

# File activerecord/lib/active_record/relation.rb, line 260
def size
  loaded? ? @records.length : count(:all)
end

Therefore, using .size instead of .count will avoid an extra database query each time it is called if your ActiveRecord::Relation is already (eager) loaded!

This is especially counter-intuitive, since .size, .count, and .length all behave the same when sent to an instance of Array in ruby. ¯\(ツ)/¯

Today, while putting finishing touches on a fin-tech MVP I'm building, I realized I needed to hit an external API twice before loading one of the pages... ew. Totally not cool, and definitely wouldn't give a programmer like myself a big-O (please look up big-O notation if you didn't get that. I'm funny, I swear).

Anyway, since I'm ABSOLUTELY NOT willing to increase my server response time by 50 ms, today was the day that I learned how to make concurrent API (HTTPS) requests in ruby.

Please find below boilerplate code demonstrating how multithreaded requests can be made in ruby:

require 'httparty'
require 'nokogiri'
require 'thread'

def return_parsed_response(url)
  HTTParty.get(url).parsed_response 
end

threads = []

parsed_response_a = nil
parsed_response_b = nil

url_a = 'https://snapagram.com'
url_b = 'https://twitterface.com'

threads << Thread.new { 
  parsed_response_a = return_parsed_response(url_a)
}

threads << Thread.new { 
  parsed_response_b = return_parsed_response(url_b)
}

# wait for threads to finish execution before continuing
threads.each(&:join)

Note: There is no need to start a thread after creating it, it begins running automatically when CPU resources become available.

I hope you found this quick tutorial on multithreading in ruby helpful!

Today, while putting the final touches on an appointment scheduling engine, I noticed some odd behaviour in my tests.

I discovered that the failing tests were related time zones, and more specifically, to crossing daylight savings time boundaries. This brief article will demonstrate how to easily show time (in the relevant time zone) in your rails app, as well as correctly traversing date time boundaries.

Table of contents:

1. Always store time in UTC
2. How to convert UTC time into a users' local time zone
3. How to traverse daylight savings time boundaries
4. How to convert local time back to UTC

1. Always store time in UTC

Always store time in UTC (Coordinated Universal Time) in your database (often the default setting).

Why? Because it will ensure that you can easily compare times in your database across time zones. Is 5:00 pm EST before 3:00 pm PST? This question would be much easier to answer if both times were in UTC and were same same.

If you wanted to compare relative wealth, you wouldn't compare two peoples' net worth in USD vs Yuan. You would pick one currency to compare wealth in.

Keep your times in UTC in your database, and thank me later.

2. How to convert UTC time into a users' local time zone

Lucky for us, rails makes converting time from UTC to another time zone very easy.

It is this easy:

$ irb
:001 > require 'active_support/all'
:002 > time_zone = ActiveSupport::TimeZone["Eastern Time (US & Canada)"]
:003 > Time.now.in_time_zone(time_zone).advance(days: 1)
=> Tue, 19 Nov 2019 23:52:47 EST -05:00
:004 > Time.now.in_time_zone(time_zone)
=> Thu, 14 Nov 2019 23:52:48 EST -05:00

3. How to traverse daylight savings time boundaries

To avoid surprises when traversing daylight savings time boundaries, use the advance method:

$ rails console
:001 > time_zone = ActiveSupport::TimeZone["Eastern Time (US & Canada)"]
:002 > Time.now.in_time_zone(time_zone).advance(days: 115)
=> Sun, 08 Mar 2020 23:52:47 EDT -04:00
:003 > Time.now.in_time_zone(time_zone)
=> Thu, 14 Nov 2019 23:52:48 EST -05:00

If instead of advance you try one of the following when traversing daylight savings time boundaries...

• {{X}}.days.ago.in_time_zone(...)
• {{X}}.weeks.from_now.in_time_zone(...)
• (Time.now + {{X}}.days).in_time_zone(...)

... You will find your output is inexplicably off by 1 hour.

$ rails console
:001 > time_zone = ActiveSupport::TimeZone["Eastern Time (US & Canada)"]
:002 > Time.now.in_time_zone(time_zone)
=> Fri, 15 Nov 2019 00:00:01 EST -05:00
:003 > 115.days.from_now.in_time_zone(time_zone)
=> Mon, 09 Mar 2020 01:00:02 EDT -04:00

Always use advance when traversing daylight savings time to save yourself the headache of being off by 1 hour (as per above).

4. How to convert local time back to UTC

Finally, let's say that you want to convert local time back to UTC and into a DB ready string. It is this easy:

Time.now
  .in_time_zone(ActiveSupport::TimeZone["Eastern Time (US & Canada)"])
  .advance(days: 1)
  .utc.to_s(:db)

Recently while debugging a rails test with a byebug command, I noticed byebug had fired twice:

[39, 48] in /Users/.../text.rb

[39, 48] in /Users/.../text.rb
   39:   		[:from, :country]
   40:   	end
   41:
   42: 		def post_initialize
   43: 			byebug
=> 44: 			self.from ||= self.class.const_get('TRIAL_NUMBER_' + country)
   45: 	        self.twilio_client = Twilio::REST::Client.new
   46:   	end
   47:   end
   48: end


   39:   		[:from, :country]
   40:   	end
   41:
   42: 		def post_initialize
   43: 			byebug
=> 44: 			self.from ||= self.class.const_get('TRIAL_NUMBER_' + country)
   45: 	        self.twilio_client = Twilio::REST::Client.new
   46:   	end
   47:   end
   48: end

I had to Ctrl+C out of the frozen byebug REPL, which led to the following error:

Errno::ENOENT...connect(2)...DRb::DRbConnError

2. Cause of byebug problem:

As of rails 6, tests are run parallel by default.

Since multiple workers were executing my tests all at once, the workers all eventually reached the byebug statement in my test, which started multiple byebug REPLs at the same time, causing the byebug REPL to freeze.

3. Solution to frozen byebug REPL:

Only run one thread at a time when debugging a test with a byebug statement:

PARALLEL_WORKERS=1 rails test

Knowledge Gained / Discoveries:

1. How to Start a VM for Ruby on Rails Core Development
2. Jumping Into the Console to Explore Changes
3. Rails is Comprised of a Collection of Standalone Gems
4. Learning How to Contribute to Rails is Easy
5. Running Tests for Rails is Easy
6. Ruby Has Great Introspection Methods

1. How to Start a VM for Ruby on Rails Core Development

After perusing Alex Kitchen's rails blog post and using instructions in this repository, it was simple to get a VM up and running using the latest release of rails.

This allows you to run tests / explore new features, patch bugs and issue pull requests (if you want to be a rails contributor), as well as alter code to see the impact.

2. Jumping Into the Console to Explore Changes

After using instructions in this repository to set up a rails development box, you can easily drop into irb (with local rails repos loaded) using the console tool that ships with rails available at rails/tools/console.

This allows you to easily experiment with any modification you make.

Want to know where a method on an object is defined? Try [OBJECT].method(:method_a).source_location or [CLASS].instance_method(:method_a).source_location in irb and find out!

If you are looking for where a ruby builtin method is defined, you'll have to check the C source code; look for the right C file (they're organized by class) and find the rb_define_method for the method.

3. Rails is Comprised of a Collection of Standalone Gems

Rails is comprised of a series of (mostly) standalone gems. Other than Action Mailer / Mailbox, Active Job, Action Cable, Active Storage, and Action Text, and Railties, the gems can be used outside of rails and replaced with different gems inside of rails.

As of 6.0, rails is comprised of the following core gems:

• Action Pack: routing and controllers
• Action View: view template lookup and rendering
• Active Model: non-Active Record (DB) model interfaces
• Active Record: connects and associates models with DB
• Active Support: collection of utility classes and standard library extensions
• Railties: glues frameworks together, handles rails initialization / bootstrapping process, manages rails CLI, provides generators core

And supplementary gems:

• Action Cable: WebSockets integration / support
• Action Mailbox: routes incoming emails to controller-like mailboxes for processing
• Action Mailer: email delivery
• Action Text: rich text content and editing
• Active Job: queueing framework for delayed jobs
• Active Storage: easily upload, reference, and associate files in cloud storage

4. Learning How to Contribute to Rails is Easy

Rails encourages everyone to contribute to Ruby on Rails! It's easy to learn how to contribute to rails by reading their guide.

If you contribute, your name gets put on this sweet list of rails contributors!

5. Running Tests for Rails is Easy

After using instructions in this repository to set up a rails development box, running tests is simple.

With the dev box running, running tests is simple:

# All tests (be prepared to wait):
cd rails
bundle exec rake test

# Component tests:
cd railties
bundle exec rake test

# Directory within component tests:
cd railties
TEST_DIR=generators bundle exec rake test

# Specific file tests:
cd actionview
bundle exec ruby -w -Itest test/template/form_helper_test.rb

# Single test:
cd actionmailer
bundle exec ruby -w -Itest test/mail_layout_test.rb -n test_explicit_class_layout

For more tips and tricks (e.g. testing with a specific seed or DB), check out the rails testing documentation.

6. Ruby Has Great Introspection Methods

Not sure what class an object is, or what parent classes / modules it has?

object_a.class.name
object_a.ancestors

Not sure if an object is an instance of a certain class?

object_a.instance_of?(ClassA)

Not sure what methods an object / class has?

ClassA.methods
ClassA.instance_methods

Not sure if a method is available to a given object?

object_a.respond_to?(:method_a)

Want to see the instance variables of an object?

object_a.instance_variables

Other Takeaways

• Checking out the *.gemspec in the root folder of a gem quickly shows you its dependencies
• There is a great guide explaining how rails autoloading / reloading works. Check out rails/activesupport/lib/active_support/dependencies/autoload.rb to see the code
• In the first level of rails gems (e.g. Active Record), the lib directory contains a file with the name of the module (e.g. active_record.rb), which configures how the gem is loaded when it’s started up
• Some gems have a rails/generators directory which holds the generators pertaining to the gem (e.g. rails g model)
• git log -S --reverse --patch --pickaxe-all; A way to search commits in reverse order with all code changes

1. Why do startups fail?
2. Why validate your startup idea?
3. How to validate you startup idea

1. Why Do Startups Fail?

According to a recent CB Insights study, the most common reason is no market need. Said another way, the reason almost half of startups fail is not enough people want to buy their product.

Common reasons startups fail:

• No market need (42%)
• Ran out of cash (29%)
• Not the right team (23%)
• Outcompeted (19%)
• Pricing / cost (18%)
• Poor user experience (17%)
• No business model (17%)

Note: most startups surveyed indicated multiple reasons - above list adds up to over 100%

2. Why Validate Your Startup Idea?

Put simply, validating your startup idea helps you ensure that your startup is less likely to fail for any of the above reasons; this saves your team time and money. Further, validating your idea can be done relatively quickly at little or no cost.

3. How to Validate Your Startup Idea

There are several common ways to validate your idea:

A) Google AdWords (low effort / accuracy)

B) Check if competitors exist (low effort / accuracy)

C) Check if a community exists (low effort / accuracy)

D) Market research (low effort / accuracy)

E) Create a landing page (medium effort / accuracy)

F) Create an explainer video (medium effort / accuracy)

G) Wizard of Oz (medium effort / accuracy)

H) Sell your idea to 10 people (medium effort, high accuracy)

The above are all different ways to quickly test whether your idea might solve a customer pain point for an appropriate market size (i.e. amount of potential customers). Said another way, they help you test whether your idea could become a successful business. Let's explore the above ways in more detail below.

A) Google AdWords (low effort / accuracy)

A quick and dirty way to validate an idea is to check whether people are searching Google for associated keywords. If lots of people are searching Google for phrases pertaining to your product, you might be on to something.

B) Check if competitors exist (low effort / accuracy)

Another easy way to begin validating your idea is to check whether any competitors exist in the space. If no similar products exist, it might be an indication that there is no market need. It might also indicate that your idea is too early (i.e. people aren't ready for it yet).

C) Check if a community exists (low effort / accuracy)

Do conferences, groups, or online forums exist in the space? If so, are they talking about the problem you are trying to solve?

D) Market research (low effort / accuracy)

Check relevant books, journals, newspapers, blogs, podcasts, etc. Are they discussing the problem your idea solves? If not, create a short survey and send it to 100 of your target customers.

E) Create a landing page (medium effort / accuracy)

A great way to see if potential customers are willing to buy (or sign up for) your product is to create a landing page describing your product. If visitors click buy / subscribe, let them know that the product is under development, and ask for their contact information for future product updates.

F) Create an explainer video (medium effort / accuracy)

Creating an explainer video allows you to visually show potential customers what you plan to sell. By posting links to the video in various online communities (e.g. Reddit, Hacker News, Facebook, etc.), you can quickly receive vital feedback.

G) Wizard of Oz (medium effort / accuracy)

The Wizard of Oz consists of building a rudimentary service for customers, and manually doing everything behind the scenes. It's a great minimum viable product (MVP) for non-technical founders with technical ideas. It is also a great way to inexpensively gauge potential demand.

For example, imagine you thought it was a great idea to build an online company that sells and ships hats. Instead of building the company right away, you could build (or pay someone to build) a basic website that listed hats for sale in your neighbourhood. When an order came in, you could physically buy and ship the hat yourself.

H) Sell your idea to 10 people (medium effort, high accuracy)

By far, the best way to validate your idea is to sell it. Given that the most common reason startups fail is no market need, selling your idea to 10 people is the best way you can validate it before you spend the time and resources required to build it.

"I really thought I had blown my chance at the big leagues. I felt like I was at rock bottom, and things couldn’t get any worse. In which case, why not start my own company?"

Discover why Andrew David Osborne founded Minifridge Media - a Toronto video production agency shaking up corporate videos.

Hi Andrew! What's your background, and what's Minifridge Media?

Minifridge Media is a video production company in downtown Toronto that I started in January 2016. We create commercials, explainer videos, and corporate videos for businesses and brands across the GTA. Our goal is to create video content that is of a higher quality than the traditional bland 'corporate video.’ We want our videos to look like TV commercials, even if they’re for a local insurance company.

Really, what it is is an excuse for me to do what I’ve always done, which is write, produce, direct and edit videos. As a kid my favourite toy was the camcorder; I scored a 98% in high school videography class (that sounds like I’m bragging but it actually wasn’t considered cool at the time); I studied film at Queen’s University and made comedic segments for Queen’s TV. I’ve had a lot of side projects, from a docu-series on stand-up comedy, to an instagram skit channel called @thatskitcray that had 25K followers at its peak.

So I make videos whether I’m getting paid to or not. But it sure is nice to get paid for it.

What motivated you to get started with Minifridge Media?

The truth is that I lost my job and couldn’t find another one. My first big ‘film job’ out of school was at this really high-end editing firm in Toronto, which I had to intern at for months to get. I was an assistant editor on commercials for big brands like Rogers, Orville Redenbacher’s, and FedEx.

"Getting a good job in the Toronto film business is tough. I somewhat miraculously did it once; doing it twice seemed nearly impossible."

I lost that gig in November 2015 and landed right back to where I was when I graduated—going around town, handing out resumes and looking for a job. Getting a good job in the Toronto film business is tough. I somewhat miraculously did it once; doing it twice seemed nearly impossible.

That was kind of a dark time for me. I really thought I had blown my chance at the big leagues. I felt like I was at rock bottom, and things couldn’t get any worse. In which case, why not start my own company?

In hindsight, I realize that I still had a lot to lose at that point. But it doesn’t matter if you’re actually at rock bottom—you just have to feel like you are, and then it’s easier to take a big risk. So go ahead and lose your job, and maybe get your girlfriend to dump you while you’re at it. You’ll have the next Apple on your hands.

How have you attracted customers and grown Minifridge Media?

When Minifridge Media started, I cold-called just about every company in Toronto asking if they needed a video. The thing is, we were brand new and didn’t have a portfolio yet. It makes me cringe to think about, but it’s true. I was calling businesses asking if they wanted commercials, when I hadn’t even made one yet.

Eventually one guy told me to just stop calling him until I had made some videos. So I made some low-budget videos for my dad’s company, and I made an explainer video for my friend Bryan Gold’s influencer-marketing company #Paid.

"The fear of failure outweighs the fear of potentially bothering some nice executive out there."

Once I had some work to show, the cold-calling went a little bit easier. But it’s still hard. I do it anyway, because for me, the fear of failure outweighs the fear of potentially bothering some nice executive out there.

What's your business model? Why do you focus on corporate videos?

Our business model is this: if you need video content made for your business, and you have a certain amount of money (usually starting at $5K, but sometimes it’s as high as $50K), we’ll make it for you. Part of that cost covers fees for writing, producing, directing, and editing. Those fees are the company’s profits.

We started focusing on corporate videos because, especially at the beginning, we were aware of our size and knew that Old Spice wasn’t gonna come calling to handle their Super Bowl spots. So I thought, let’s take this dusty old genre of corporate video, which has a reputation of being cheesy and boring, and make videos for Toronto businesses that look and feel more like TV commercials.

After years of this approach, we’re now being approached to do real commercials; we just finished one for Chuck’s Roadhouse Grill that would be totally at home playing on TV in front of a Leafs game. So I think that’s the direction we’re heading in, although we’re still doing plenty of corporate videos.

What do you think has had the biggest impact on your sales since you started?

I think that as our portfolio gets better, it’s easier to convince companies that we can handle their video. Our early clients took a leap of faith on us. Now, we have quite a large portfolio with a lot of variety, which is reassuring to potential clients.

I’ve also learned that there is so much that’s out of our control as salespeople. We don’t know what’s happening behind those closed boardroom doors. You could pull your hair out blaming yourself when a deal doesn’t go through, when really you were doomed from the start for some internal reason you could never have predicted, or done anything about.

Have you found any resources or habits particularly helpful or advantageous?

There are a lot of resources that help me make professional videos; websites like Mandy (the casting site, not the insanely cool Nicolas Cage movie), or Voices.com with its database of voiceover actors, or Motion Array, which has After Effects templates.

As far as habits go, I wish I could tell you that I get up at 5AM every day, crunch out a bunch of one-handed push-ups and eat raw eggs for breakfast, but that’s not the case. I actually wake up closer to 8AM and do those things. And they really help.

Do you have any helpful advice for other aspiring entrepreneurs / wantrepreneurs?

Just start and get the first year over with.

The first year is the worst, and when it’s done you’ll have a pretty good idea of whether your business will work or not. So take Nike’s advice and just do it already.

Thanks for sharing Andrew!