TL;DR

Getting people to pay for things is hard & starting a company is only fun at the start, but damn you'll learn a lot. 🙂

In 2018 I co-founded a startup.

Burgundy Labs was founded to primarily support the development of one product: TimeSlot.

And although TimeSlot is being used today, I personally consider the endeavor a failure. It sucks to put into writing because every couple of months I get a sudden rush of energy to continue improving TimeSlot, or shoot out some e-mails to prospective leads, or sync up with my co-founders to brainstorm ideas, but unfortunately those brief periods of hyper-focus haven't translated to any meaningful success.

I'm mainly writing this post for two main reasons:

1. I want to start blogging on topics, and felt too overwhelmed starting with a technical blog post.
2. I firmly believe that failures should be shared and learned from.

So - hopefully this post gives some useful wisdom, or at least is entertaining!

The Creation of Burgundy Labs

Sometime around 2018 I was a writing center coach at Michigan Technological University. I was studying Psychology & Computer Science, but as a coach I primarily worked with students on writing papers and working on speaking skills, English as a second language, or graduate dissertations. As a coach and a student, I had the somewhat unique experience of both scheduling learning center appointments, as well as having them scheduled with me.

And the experience sucked.

I won't be naming specific competitors, but there are 2-3 major SaaS offerings for university learning centers, and all of them lack some combination of features, user experience, or affordability. As an aspiring software engineer, I saw an opportunity for improvement, and a great project to showcase to future employers. TimeSlot was created to address all of the needs of learning centers: scheduling, reminders, analytics, feedback, user management, etc.

Lesson one: a startup is not a way to showcase skills to future employers.

That was, in retrospect, a bad mindset to start a company with. I had originally partnered with a university enterprise to help with the planning, development, and support of creating TimeSlot. I was a member of the enterprise already, and by incorporating the project into a university-sponsored program, it allowed me to count credits toward my degree, have a team to lead & build it with, and have a process for passing the project down to future students.

This worked somewhat well for a year or so. We were all new developers, the writing center we partnered with gave us amazing feedback & patience as we built out TimeSlot, and we felt like we were making real improvements.

Except it wasn't enough. I knew I wanted TimeSlot to be bigger than just my university, and I thought I had an opportunity to create something successful. This is when I had started looking at finding co-founders who shared my vision, and would be interested in building TimeSlot out into the product I knew it could be.

So, now we have three co-founders, a good product idea, and a drive to build something great! But there's a problem - we don't own our code. Partnering with our campus enterprise was a great idea when confined to developing it for one university. Now that we wanted to take it into a full-fledged SaaS LLC, we needed to be sure we owned the product, code, etc.

Thankfully we avoided any conflicts over ownership after exchanging many e-mails back & forth with the head of the enterprise program. We made our case for wanting to take TimeSlot further, and leveraged the great relationship we had with the writing center and enterprise programs to make that dream a reality. There was also a well-known startup from MTU that had similar success with building out their product on-campus. But -- we did it! TimeSlot is now able to be a company. We owned the code, and we were able to continue working within the enterprise program as a corporate partner rather than an in-house project.

Companies are Not Fun

Everything changed immediately. As an enterprise project, we really didn't need a lot of oversight, permission, or structure. We moved quickly with building TimeSlot out alongside feedback we got from students, coaches, and administrators at the center. The second we became a corporate partner we had to begin onboarding as a vendor at the university, answer tough questions from the learning center committee, defend our decisions on pricing, create an SLA, create Terms of Service, Privacy Policies, and deeply understand FERPA.

Lesson two: you have to be serious

We thought we were in the clear after getting the sign-off email that we could own the rights to TimeSlot. We were definitely not prepared for the numerous legal hurdles with committing seriously to getting Burgundy Labs off the ground. To start, we needed to legally incorporate as a business entity. We chose to use an LLC with each co-founder taking 33.33% ownership. We had to draft an operating agreement, file articles of organization, and officially receive our EIN to begin conducting business. Opening a bank account was a first priority to accept payments. To this day we still have our original business bank account because in order to close it they require all three co-founders to be there in person. Later on, we settled with using Mercury - which matched our ambitious energy & gave us the tools to hit the ground running. From there, we registered for a Stripe account, and utilized our business account to get Cloud Firestore, Digital Ocean, and our Google Domains all set up.

The writing center we had been working with agreed to start paying for TimeSlot as our first official subscription - with a pretty hefty discount code as a thanks for the support in beta testing the software. But we were officially making money! More excitingly, we were officially profitable. By utilizing the free tier of Cloud Firestore, and hosting our API & application in a single Digital Ocean VPS, the monthly expenses we were incurring were just barely covered by our new revenue. This was by far one of the most exciting moments in Burgundy Labs' history.

This is a latest graph of our MRR. Are we profitable? Yes! Are we successful? Check the title of this post 😎. We knew then that we had to expand outside of our university, but we had no idea how difficult that would be.

We had great advice & connections from the administrators at the MTU writing center, a big piece being that we needed to attend [the IWCA conference] (https://writingcenters.org/). I unfortunately was not able to attend, but my co-founders were, and received some amazing feedback. People loved the product - but we weren't a good fit for any of them. Despite offering many of the same features as the software they used, our lower pricing alone wasn't enough to justify switching systems. Some wanted tighter integrations with their library services software - an area we were interested in to potentially expand into, but not something we could support at the time. Other centers wanted us to adhere to data requirements in Canada so they could sign up there. Later on we connected with a center in California that wanted support for certain in-state data requirements & integrations. At the end of the day, we found that most administrators weren't convinced they should switch to TimeSlot, and we needed to find out why.

Shortly after the conference the psychology background in me dove right into the data. I crafted surveys for students, coaches, administrators, and sent them to as many participants as I could. The data we got back was extremely useful in identifying key areas of improvement, as well as justifying the product using actionable metrics. The key takeaways from our survey spree:

1. Those who have used TimeSlot like it better than other solutions.
2. TimeSlot is missing some key features.
3. Bugs are creating a negative experience.
4. Our UX is in a good place.

Lesson three: you can never have enough feedback

I was very pleased to see #4 justified in our survey response. From the very beginning we made a deliberate effort to continually survey our users with task flows, interviews, card sorting sessions, surveys, and easy tools to provide feedback within the app. We used this feedback constantly to drive our decisions.

Finding out exactly what your users want is an excellent way to continually provide a great product - there were some easy wins like Google Calendar integration that we could incorporate in a short period of time but resulted in massively improved experience for scheduling. This part of running a company is a lot of fun, because the impact you feel you're making is reflected in actual data, and seeing feedback submissions slowly shift from bug reports to feature ideas aspires you to keep building.

We began sending out marketing emails highlighting some results on student feedback of existing solutions, showcasing new TimeSlot features that addressed the most requested & desired ones we've received, and providing numerous promotional codes as extra incentive to try out our demo.

Overall, these e-mails had some great results! We had a pretty solid contact list from the conference, and had paid for a lead list composed of learning center administrators across the US.

(are these numbers good? who knows! really - who knows?)

Unfortunately, these did not translate into any new subscribers.

A Customer ≠ A Company

Turns out, many customers is the key to a company. Around 2019-2020 we had on-boarded 3 new learning centers to TimeSlot - all still within MTU. We were thrilled to see some growth, have access to additional funds to play around with advertising, software licenses, etc. and ultimately to have access to more student, coach, and administrator feedback. We identified and addressed a lot of feature requests that we never considered in our initial use-case of writing centers. Within a few months we rolled out multi-location support, asynchronous appointments, coach services, a daily viewer, and made significant progress in adding a groups feature.

From a technology perspective between 2018-2020 we slowly migrated from Play Framework in Java to ASP.NET Core in C#, and even made our first company open-source contribution!. After the initial migration was complete, we even open sourced TimeSlot V1.

These changes were necessary to continue to implement features at the rate we felt we needed to. Additionally, we had the desire to start exploring the possibility of bringing in new engineers. But more importantly, a good re-write is a perfect way to boost motivation, start fresh with a clean codebase, and learn new things.

Lesson four: product isn't enough, hire a sales person - you aren't one.

So now we have a fresh and exciting re-write of TimeSlot, three newly on-boarded learning centers, tons of awesome feedback, and a whole host of new features to tout to potential customers. "Build it and they will come" right? Nope! Scroll back up to lesson one. If you want to run a successful company, it has to be a priority. If you make a list of your top 5 worries you have each day, let me give you the 3 you should start out with:

1. How am I going to convince someone to buy this? Or even to try it out?
2. How can I spend my company's money wisely?
3. How will I ensure I can keep the existing customers happy?

For me, #2 was easy. We needed company accounts for beta testing, authorizing access, and communicating with people as an official company. For us - paying for that felt like a bad idea. Why immediately spend around half of our revenue on just enabling us the ability to email? Turns out, at our size we could handle everything on a free tier of Google Workspace with our domain emails forwarding to our personal ones. We could receive, respond to, and send emails as burgundylabs.com without having to sink funds into a monthly subscription. It goes further than that - how can you ensure you're spending money where it makes the biggest impact? As three co-founders we had all agreed to take no income from the company as we got it up and running, if you do have employees however, ensuring compensation is motivating is essential to building a solid start up. Additionally, how can you push technical means to reduce expenses? We had a couple that we absolutely needed: a transactional email service, hosting for our app & API, and a database.

As mentioned before, the majority of our traffic was supported on the free tier of Cloud Firestore. We worked to reduce our API calls to only those that were necessary, allowing us to squeeze as much functionality as we could before hitting a rate limit that would push us over into being charged. Sending transactional emails is something we did not want to build in-house, but after quite a while comparing options, we found that Postmark would cost about as much as a dedicated server would, but provided a fast way to get the functionality we needed built into TimeSlot. Lastly, we were able to squeeze a messaging service, an API, and a web app into a single VPS from Digital Ocean utilizing docker compose. Buddy helped us orchestrate automatic deployments with one of their free pipelines, and gave us the ability to set up Slack hooks to get notified on our deploy statuses.

Fully up and running? Our costs top off at around $50 a month.

As for how we get people to try out and pay for TimeSlot? This is where I realized that I am not a sales person. I do not have the ambition, time, or social ability to cold call people, advocate and sell a product, or convince anyone that they should buy into what we built. Burgundy Labs desperately needed someone to handle marketing, sales, and support of existing clients. I had played around with Facebook ads, Google's AdSense, and even began e-mailing administrators personally to introduce myself & TimeSlot. Nothing really worked.

Out With a Whimper

Lesson five: loss of motivation is a company killer.

As of today, I've lost all excitement around running a company. I've graduated university, and I've now been working as a full-time engineer for around two and a half years. I no longer have the free time that being a student granted me. I'd imagine with any profitable side-project there comes a day when responding to user emails or fixing bugs starts to feel more like a chore than a puzzle to solve. I firmly believe TimeSlot makes scheduling learning center appointments easier for thousands of students, I believe we have had a strong impact at MTU, and I believe the learning center (and higher education as a whole) software market has a massive opportunity for improvement.

What's next?

Who knows! I still respond to & fix major bugs, and have slowly been building a Jamstack-esque replacement of TimeSlot using React & Chakra UI, but so far it's served more as a playground to learn cool things than a serious endeavor. Burgundy Labs the LLC will keep going as a great way to support any future ideas myself or our co-founders come up with, and maybe one of these bursts of ambition will result in TimeSlot taking off 🚀. As of now, I'm fine keeping it in maintenance mode and focusing on career development. I have learned so many things while building TimeSlot & running Burgundy Labs, even if a startup is not a way to showcase skills to future employers - it sure is a great way to develop skills employers look for. When interviewing for my current role, my failed start up background was a massive selling point. Here are just a few things I learned with Burgundy Labs:

• Branding, design,and mock-ups
• Interacting with users and providing application support
• Our legal system! Taxes, FERPA, business entity filing
• CI/CD, scaling applications, designing software from the ground-up
• Integration of countless third-party APIs & services
• Planning, scoping, and prioritizing features

Lesson five: take a chance, if you fail - you'll learn a lot