In this article I will share the story of how I became CTO of a software as a service (SaaS) company. It all started about 3 years ago when I was going to hackathons for fun.

At the end of the article you can find some tips and advice I would give to aspiring entrepreneurs as well as some reading recommendations.

It was – and still – is a wild ride!

Our company team (we now have 8 more employees!)

Although I have a good knowledge of entrepreneurship, don't just take my advice at face value. Learn from books, from other entrepreneurs, and from your environment in order to triangulate how best to act in a given situation.

My First Hackathon – Which I Lost

It might sound off, but I had no interest whatsoever in entrepreneurship or business 3 years ago. I was more of a researcher in spirit than an entrepreneur.

From studying memory at the molecular level, to helping schizophrenic patients learn better, or predicting consciousness recovery in patients with traumatic brain injuries, my mind was deeply focused on the frontiers of science.

However, I had a deep passion for programming and for finding ways of building tools that didn't exist before.

Like the time I built a brain computer interface that was compatible with a Transcranial Direct Current Stimulation electroencephalographic headset (that is, it stimulates the brain by giving shocks and lets you control a kind of ping pong game). I just love to build stuff.

Cutting edge graphic from my brain computer interface

So three years ago, my brother wanted to find a new job as a software developer. We figured out that we could attend hackathons to help him get noticed by recruiters.

It was my first hackathon so I was pretty excited to spend two days building something. Our team was composed of myself, my brother, his friend, and one more member (who didn't do a lot, but was still there).

It was two days of heavy coding, and at the end we came up with a pretty cool algorithm to pattern match people with jobs given some characteristics.

On top of that, I met nice people that, like me, love to build stuff. We ended up among the finalists and came in fourth during the final presentation.

Here I am trying to figure out why the clustering is not working

What I learned From My First Hackathon

It was a bit of a bummer not to win, but I realized something important then: except for the participants, no one really cared what I coded during these two days.

It was mostly the presentation of what we wanted to build that mattered. We should have spent a bit more time making a very compelling PowerPoint instead of focusing on the development of an algorithm!

It was a fun learning experience, but my brother didn't get a job out of it – so we were back at square 1.

My Second Hackathon – in Which We Won a Special Prize

I was ready to take a small break from hackathons for a while. However, my brother decided to sign us up anyway. So his friend and I to go to another hackathon right after the first one. I would have refused as I had other stuff to do, but he had already paid the sign up fees.

This hackathon was a bit bigger than the previous one and there were still a bunch of recruiters there. We figure that this could be our second shot at getting him a job.

The theme of this hackathon was open data and environment. So we were in a good position to make something cool with my background in machine learning.

A lot more people where present at HackQC which was nice!

Knowing that the presentation was everything, we decided to be a bit more strategic with this hackathon. We combed all the different prizes we could win and selected the one with seemingly the least competition. The project would deal with the prediction of combined sewage overflow.

We then split up our team of four (another friend of my brother's joined in) so that half of us were working on the coding and the other half on the presentation.

The name of our team was “Égout Quebec” which translates to Sewage Quebec (branding wasn’t our strength). Here is the excerpt from our competition log on DevPost in French:

ÉGOUT QUEBEC permet de prédire le débordement des égouts et d’en avertir les amateurs d’activités aquatiques. Ainsi les personnes désirant aller faire des activités aquatiques pourrons éviter les zones polluées par les déversements d’eau usée. De plus, des conseils seront dispensés aux gens des différents quartier, de façon à réduire les risques de débordement.

ÉGOUT QUEBEC utilise une technologie basée sur une intelligence artificielle. Celle-ci peut déterminer lorsque les égouts déborderont. Ses analyses et calculs sont basés sur des données disponibles sur le site de donnée Québec. Finalement, les différentes villes auront avantage à utiliser ÉGOUT QUEBEC.

Grâce aux prédictions et aux analyses de la plateforme, il sera possible de concentrer les ressources de la ville aux endroits les plus problématique.

All this basically translates to “we found a way to solve the problem using a random forest + a bunch of data”.

We actually ended up winning a $1000 prize, which was huge at that time! We even got a nice glass trophy in the shape of a water droplet. It was less challenging than the previous hackathon because we had a better plan for what we needed to do.

Here we are at the podium (still technically fourth place though).

What I learned From My Second Hackathon

This hackathon made me realize that presentation was indeed important. But I also discovered that focusing on problems that people don't find interesting is a good way of increasing your chance of coming out on top!

Winning felt good and I was ready to take my share of the $1000 prize and call it a day...

My Third (and Last) Hackathon – Which We Kinda Lost Again

However, the $1000 prize came with an automatic fast-track to the semi-final of yet another hackathon! This one had higher stakes with a $25,000 prize.

We met up at a coffee shop to figure out if we wanted to split up the money or to use it in order to take our project to the next level.

After looking at the other participants' projects and the rules of the competition, we decided that we actually had a good shot to at least get to the finals. This would unlock some more funding which we could use at will and would give us a nice trip in the summer to a lake in Ontario.

This hackathon wasn't like the others in the sense that it ran for the whole year. It was more of a take-home hackathon, which was great for me since I didn't have to do that insane two-day time crunch routine over a weekend.

We changed our name to EGC Labs and managed to get a website together to advertise our sewer overflow prediction solution (which was working surprisingly well). We then went to the semi-finals competition in Ontario, and to our amazement we moved on to the final!

Here we are as finalists! I didn't go all the way to Ontario for the semi-finals, though.

This was great! We had a very good shot at winning more than a small stipend, and maybe starting a business out of this thing. To help us bootstrap ourselves, Aquahacking generously gave us $2000 and École de technologie supérieure (ÉTS) gave us $1000 for travel expanses.

However, we still didn't have any customers for our solution, which was a bit problematic.

We tried to contact a bunch of cities in Quebec in order to see if they would be interested in our sewage overflow application. We had some pretty advanced discussions with a few cities, however their process was so slow that we got very near to the finals without any concrete validation.

The final was a 5 minute presentation in front of a big audience with some investors present.

Things got a bit more tricky when we got closer and closer to the presentation date. The rest of my team started to become less and less responsive. I ended up not being able to reach my brother's friend who had joined at the HackQC competition.

This quickly followed by my brother losing all interest in the competition and focusing on other stuff. We were left with myself and my brother's other friend (Félix) who joined in the very beginning.

He was also starting to slip out of the picture because nothing seemed to be moving forward, as I was the only one left coding. I wasn't very interested in that project either, however one thing I hate is half-backed projects (even more when they are public).

Our faces were plastered everywhere

I felt that it would have been a waste to stop so close to a conclusion. So I took it upon myself to jump start the project by coding the app's user interface, getting some branding going, and creating our business cards for the event.

As things started to pick up Félix started to become more and more involved (which was a blessing because he was the one pitching!).

We were still finalizing the PowerPoint the night before the presentation in the hotel room. After all this hard work we had something pretty solid (by my standards at the time, anyway). We've ended up winning fourth place in the competition:

Us receiving the 4th place trophy (again) with no money whatsoever associated with it haha

We went from a team of 4 to 2 people and were able to get that far. However, it was exhausting since I had to do so many different things that were not in my core zone of competency.

What I learned From My Last Hackathon

I learned two very important lessons during that adventure:

• Having motivated teammates is the most important asset in any endeavor. If we had everyone pulling their weight we would have had more chance to win!
• For a startup, having clients is the ultimate measure of success. We did everything right, except making sure that we had paying customers. In the end this is what kept us at 4th place.

We won a big $0 in that part of the competition, and once again I thought that was it. I had coded some cool Flask applications, went to the final of a big hackathon, and learned some valuable lessons. Until I realized...

How I Learned About Entrepreneurship at An Incubator

Being part of the finalists of Aquahacking automatically gets you a spot in one of the provincial incubators for startups, which happened to be Centech for us in Québec.

I didn't really know what an incubator was (except in a biological sense), so I wasn't particularly excited. We had to make a pitch for our "startup" to the incubator panels even though we had a reserved spot. I let Félix do it without me, as I had other stuff to focus on.

Centech is inside an old planetarium so it has that funky circular shape. It's a pretty cool place.

At first I didn't go too often to the entrepreneurial classes and I was starting to think that this whole hackathon-thing was becoming a huge time-sink. However, I stuck to it because Félix was very motivated by the whole experience.

So I decided to give it a serious shot. I started attending the entrepreneurial classes (which were amazing), I did the homework, and I tried really hard to make our sewage company work.

Lots of entrepreneurs in our 2018 cohort, try to find me!

Frankly speaking, it was amazing. It was genuinely fun to try and make something novel. And being mentored by people that had built incredible products that helped millions of people was incredible.

The class that I was in was also very motivating, as we had people from all backgrounds and oddly enough most of them were graduate students, like I was!

I really got the bug for entrepreneurship. It was like doing research, except I could directly see the results of my experiments in a matter of days. It was like combining the pleasure of discovery I had while doing an experiment with the freedom of programming for a side project.

However, after reading the books and learning the material, I realized that we'd done everything upside-down for our budding startup. We had built the technology before even validating that there was a sustainable business out of it (silly us!).

We were ready for our very first pivot, which in entrepreneurial jargon means tweaking your business in a significant way in order to not crash and burn.

How We Made Our First Pivot After Learning that Our Startup Idea Was Doomed

Our combined sewage overflow predictor was working great. However, no one was willing to spend money on it.

We were targeting cities in order for them to be able to proactively do something about the overflow of raw sewage into their rivers (which, by the way, is a worse and more frequent problem than you think). But these cities had such a long cycle to sell to that we would never be able to grow this business.

One thing that we realized during this project was that the majority of the data that was available for the competitions were in a very bad shape. It took us many hours of cleaning and we had to develop some very custom toolsets in order to make the cleaning efficient.

We had also talked to a few of the judges at Aquahacking and what they were most interested in was the portion of our business that related to data cleaning.

So that was it! We would become a data cleaning company. For about three weeks we were frenetically searching for customers, making plans on how to make this type of business work, and coding outlier detection algorithms.

This would have been us inside the datasets for the rest of our lives: Photo by [Unsplash](https://unsplash.com/@mkjr?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit">mkjr / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

However, after meeting with our mentors at Centech, we realized that what we were building was a service company. Almost no data is similar, especially when it comes from different sources.

The amount of domain expertise we would have to gain in order to be efficient in one industry would not necessarily transfer easily to another industry. There was a lot of manual work involved in this and all our ideas for making it more automated were failing.

Now, there is nothing wrong with making a service company. It's a great type of company if you are very interested in your industry. But we did some amount of introspection and we realized that we weren't really passionate about data cleaning.

We were passionate about automating work and improving efficiency through technology. Building a data cleaning company where most of the work would be manual and not very efficient wasn't very exciting for us.

We were ready to make our second pivot, which would be our largest so far.

How We Made Our Second Pivot

During the Centech program we had met two other entrepreneurs that had a problem that was complementary to ours. They had a lot of validation from potential clients whose problem could be solved by technology. However, they didn't have the technical skills to make the technology required to power their business.

I had helped them out a couple of times in order to get them started with building their web application since I'd already done something similar for EGC Labs.

Helping out other entrepreneurs without expecting something in return is very common in this type of environment. The more I helped them, the more we realized that we could get way more done if we were a team of 4 instead of two teams of 2.

We went for lunch to discuss what a potential "merger" of our two ideas would look like. After discussing for a week, we decided to ditch the EGC Labs project completely, as it had the smallest chance of success. Instead we would join forces with their idea, which was called GRAD4.

That was the second pivot for Félix and me. It meant completely dropping a project that was leading nowhere and joining another one that we were much more excited about.

Félix pitching our new company instead of the data cleaning one

During the next weeks, we were absolutely crushing it. We did everything right. We officially incorporated our company. We made a few plans as to what the actual application would need in terms of functionality so it would deliver value to our potential customers. However, we didn't wait for me to complete it to start selling it!

The other two co-founders were already on the road talking to people who'd showed interested. They were gathering checks for a 1 year subscription to our platform, which didn't exist yet. The $500 yearly subscription would start when we launched the product and we were very upfront that we were in the process of building it.

Getting people interested in your project is one thing, but getting paying customers before building a SaaS app is the holy grail of business validation. By doing so we were able to get about 15 checks that would help finance the development of the product.

We also won a $1500 elevator pitch competition around the same time because Félix was very focused on practicing his pitch.

All of these small wins compounded during the program and we ended winning a $15,000 prize at the end of the incubator called the Unicorn prize.

This was great, but more importantly we secured a spot in the next stage of the incubator which was the Propulsion program. This would secure us an office and some additional perks that would help our company succeed.

Cozy office in the basement of Centech. It was nice, but there was lots of noise because of pipes. You can see a wild cofounder working through the night.

What I Learned From My First Startup Incubator

During that part of our young company's adventure I learned a few important lessons:

• Clinging onto an idea because it was yours even though all analysis tells you it's a bad one is usually a bad idea.
• A larger founding team is more productive than a smaller one. It also allows for cheaper labor as no one is getting paid at the start.
• Asking customers to pay for an in-progress idea is not as difficult as you may think. If the pain is big enough for the customers, they are usually very supportive of having someone fix that mess. Even if the probability of success is low.
• The technology part of the business is not that important.

We Have Money, Now What?

We now had gathered a fair amount of money and we had multiple options in front of us:

• Either we keep the money and pay ourselves.
• We keep the money and don't use it in case we fail to make the app and we need to reimburse people.
• We use the money to hire people to speed up the development.

The first idea was wasteful, and it would decrease the probability that our company would succeed. The second option would just let our funds sit idle. So we decided to go for the third option.

How We Scaled Our Startup Past the Founding Team

During that summer of 2019, we made our first two official hires to help me with the development of the platform. They were software engineering interns from the ÉTS (École de Technologie Supérieure). One intern would be focused on the backend side while the other would be focused on the frontend side.

Our product was a simple CRUD application that would allow buyers who needed metal parts manufactured and suppliers of metal parts to find each other.

It was basically a sort of marketplace where buyers would create what is called a request for quote and the suppliers would create a quote to say how much they could build the part for. Pretty simple!

The technology we choose to use was the following:

• Django + Django REST API for the backend.
• React + Redux for the frontend.
• Bootstrap for the styling.
• Heroku to host both applications.
• GitHub for remote source control.

This was our setup at first. Credit: https://blog.usejournal.com/react-on-django-getting-started-f30de8d23504

Choosing the technology was up to me as the CTO, and I honestly decided to go with what I thought would be better in the long run. I was already familiar with Flask, however I knew a bit of Django too. Seeing that a lot of the functionalities I needed were already pre-built into apps made me lean toward it.

I chose React on the frontend side because I had played around with it 6 months prior and found that it was such an easier way to build applications than the traditional way I was used to.

However, in retrospect I think I would have greatly simplified the stack. I would have only used Flask for the following reasons:

• I was more familiar with Flask than with Django.
• We didn't need to have a separate frontend, as the application we needed to build was very simple. Simple templates would have been enough for a first proof of concept.

Just this would have been more than enough

However, we went with this tech and we learned a great deal in the process.

What I Learned During My First Months as CTO

One lesson I learned from this first foray into making an application customers would actually use is that overthinking scalability is oftentimes useless.

Working with what you are already comfortable with and delivering something as soon as possible is much more useful as you learn more rapidly. This is actually what is most important in a startup.

The more learning you can do (about the business, what customers want, how to talk to them) the more probable it is that the next thing you try will work.

After a few iterations, we were finally ready to launch our closed beta with the customers that had already paid for our service.

How We Did Our First Product Launch (Closed Beta)

We were able to make the first version of the application at the end of the summer of 2019 and launched it for our users (1 month later than we promised). It wasn't pretty and it was barely working.

We had to babysit our users throughout the whole process and the buyer section of the application wasn't usable. We had to do the work manually for all our buyers while the suppliers were able to create quotes.

What was great, though, was that we continued to be able to get checks from people who were interested which helped fuel development. We made a few mistakes on the hiring side, though. We hired a friend of one of the founders who, although experienced, was a jerk to the other more junior developers.

This was the first firing I had to do, and I'm glad I did it. Creating an enjoyable work environment is much more important than technical prowess, because at the end no one wants to work in a bad environment for long.

Having people stick around for the long run in a startup environment is crucial for the company's success. I believe it is one of the reasons our startup is still alive.

As development was chugging along we realized that we had to structure the company a bit more than what we were doing. Thanks to being next to so many startups and successful companies at Centech, we could learn from each other.

During that year, we focused on getting financing going (this is a super important part of business and should be prioritized). We also focused on getting some sort of marketing going, making actual designs that made sense instead of winging it, and making sure our team was staffed by full-time people instead of only interns.

We also moved from the basement of Centech to an office space with windows on the second floor which was actually pretty nice! We maxed out the capacity pretty quickly, though, and the founders had to start working in the dining area of the building so that the employees had more room.

This was way too crowded in retrospect, but at least the view was nice

What I Learned From My First Launch

I learned a great many lessons after our first launch:

Don't do an official launch. It's useless. We put so much pressure upon ourselves to impress the paying customer with a pompous launch, and we were afraid that they would be mad at us if we didn't deliver.

The truth is they didn't really care. When we sent an apology email saying that we had to delay the launch no one complained. I'm pretty sure they were actually amazed that we were able to get something up and running so quickly.

Even if you have paying customers for your SaaS application, prioritize doing manual work over building an application. In retrospect, I would have made a simple form where the buyer could upload a Zip file containing the request for a quote which would be sent to the founders' email address.

We would then send out this request manually to the manufacturers we knew would be interested in this type of work. That would have delivered value way faster to our users and released the pressure on development.

It would also have validated a lot of hypothesis we had that would have accelerated the development work.

Stay focused on very few things and make sure that this focus is explicitly written down somewhere. At some point I was building a blockchain-powered smart request for quote because it was hyped up by one of the co-founders who knew someone working with blockchain technology. That was a solid waste of time and I'm glad I killed that project soon after.

We were starting to pick up steam and we finally had something that we could show the world. It still wasn't pretty, however customers saw the value in what we were building and we knew better what was creating value and what was not.

We were ready to open our beta to increase the amount of users in our application!

How We Opened Up Our Product to More Users

After tweaking the platform using feedback from our early users, we now had a better understanding of what exactly we needed to build. We were now ready to increase the amount of people using our platform and start to increase the output of the sales (which the founders did).

This put more pressure on our application and we started to experience downtime. We knew that we had to improve the way we were building this product if we wanted to scale to more users.

We asked an experienced software architect, now part of the team full time (thanks Karim!), to help us out. This really gave us a solid direction to follow. Here is what we changed:

• We moved to AWS to have more control over the cloud environment.
• We moved to Gitlab to have an easier-to-use CI/CD environment.
• We added automated testing to our application.
• We started to migrate toward Material-UI instead of Bootstrap.

After improving the way we worked, we now had a fully working CI/CD setup and a more robust application that was rigorously tested. The amount of downtime we experienced was drastically reduced and developers were more confident about the changes they were making. It was a more enjoyable development experience, too.

Gitlab is a very enjoyable work environment and reduces a lot of the complexities with lots of tooling. Credit: https://about.gitlab.com/

What I Learned From My First Open Beta

During that period, I learned that the minimal viable product (MVP) phase of the product is necessary. But when transitioning out of it you shouldn't hesitate to ask for expert help.

We now had sales giving us more clients (which were still a bit difficult to get, but coming along at a constant pace) and the application provided more value than before.

We were ready to ask for our first real investment!

How We Got Our First Real Investment

We applied for a funding from Front Row Ventures which is a venture capital fund entirely managed by students and which only invests in student-led startups across Canada.

We met with the people from Front Row, and explained what we were doing and where we were going with all of this.

We ended up having to do a 25 minute pitch in front of a full panel of students who were asking solid questions about the business and the technology.

This was great because we knew that if we got the funding we would not only have the cash, but also new connections that could be there to answer questions and make strategic introductions for us.

It was great, some of these people went to the same university as I did!

Well, we ended up getting the funding and the people at Front Row were very helpful in many aspects of the company!

What I Learned From Getting Our First Funding

This was another important lesson I learned during that time: when choosing a funding partner, it's not only about the funding. It's also about how much help they can provide.

Front Row ended up opening many more doors for us and ensured that their investment had all the possible tools to succeed.

What Our Day to Day Routine Looked Like

Everything was going pretty well for us on the business side. However, the pace we were following was a bit worrisome. We were an archetypal startup where employees would come at the office from 9 to 5 and where the founders worked 80 hours a week.

Meeting on the weekends at the office to plan stuff out and clear up more tasks was routine.

I wasn't too happy with this because this type of work isn't sustainable in the long run – and I started to see signs of burn out in the others. We also weren't very structured, the documentation was poor, and we had almost no processes clearly mapped.

It was at that time that I started to read more about how to structure a company properly in order to maximize our chances of success (see readings at the end).

Then, out of nowhere, we started to hear about the possibility of a pandemic hitting our Canadian shores...

How We Reorganized When COVID-19 Hit

Some employees were very afraid of the virus and of getting sick. There were no cases in Canada yet, but some of the employees had family abroad in areas more advanced in the pandemic's course.

We started to think about what we could do and we realized that we didn't absolutely need to have people come in the office to do their work. All of the work could be done remotely just fine – it was just the culture that we'd set up that required people to show up from 9 to 5 every day of the week.

This type of schedule was directly taken from what we were all familiar with, but we realized that we didn't have to do like all the other companies we'd worked for.

We decided that we would allow everyone that wasn't comfortable going into the office to stay home. I personally decided to not show up to the office and most of our employees followed suit.

_As long as people had a the tools they needed, they didn't need to go into the office: Photo by [Unsplash](https://unsplash.com/@xps?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">XPS / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This was great because we soon realized that a lot of the shortcomings of our company's structure were hidden by the fact that all employees were available in the office every day. Everyone was always trying to setup a Zoom meeting at random hours or calling at any time of the day to ask for operational tasks status.

We also realized that people had a hard time finding where all the information was, and many different people asked the same thing many times.

I decided to read a bit more about how to structure remote work efficiently so we read the remote playbook from Gitlab and implemented some changes:

• We removed the silos between the different teams by making all communication public and via written messages.
• We organized the documentation so that people would put their files in a shared drive instead of sending them on the instant messaging app.
• We instated a Kanban methodology for all departments, not just the people working on the technology since tasks weren't properly tracked.
• We reduced synchronous meetings by only scheduling those that were necessary and by having the results of the meetings communicated in one form or another.

This helped a lot! However, it took time before it really took hold. People were still having private messaging discussions when everyone could benefit from what was said. Synchronous meetings were still the default for a lot of people to share information.

Here are the co-founders trying to keep 2m distance in our first pandemic meetup (and photo shoot)

But it got better. By putting a lot of effort into making remote-work work, we were drastically improving our company's productivity to a level way above that pre-pandemic.

In a sense it was helpful that we were forced to experience remote work (as we were in full lockdown for a while) because it gave us the necessary buy-in from people that were skeptical that this was possible.

There was no other choice but to go all-in to remote work, otherwise the company would've just ground to a halt. We had employees to pay, so waiting the pandemic out wasn't an option.

In the business sense, we were very fortunate as our platform was useful for the manufacturing industry which couldn't do business in person anymore.

Some startups that we knew of weren't so lucky and their whole business was now impossible to operate within a very short time frame. Most of them had to close shop or do some radical pivot.

What I Learned From Pivoting to a Remote Company Structure

The first few months of the pandemic taught me some very important lessons:

Starting a startup is very, very, very risky. If you had started a ridesharing startup in 2019 and things were going fantastic for you, you would still have had to stop that business once the pandemic hit in 2020.

No matter how prepared you are, there are always risks and unforeseen events happening on a daily basis.

Working on the company is more valuable than working for the company as a founder. What I mean by that is spending time structuring the company and making adjustments to how people work in order to increase productivity is invaluable.

You can't expect employees to do that on top of doing their regular work. It's up to the founders to set up a structure that make sense and to always be improving it.

Remote work will improve your team's productivity compared to in person work (when possible) only if you take the time to make it work. Trying to reproduce an in-office way of working remotely will lead to an obvious decrease in productivity. Drastic changes needs to be made in order for this type of work to be useful and it requires a leap of faith.

We were still growing during that time as we were hiring more people to sustain our rapid pace. We also made a major pivot in how we were generating revenue by ditching our subscription-based model to a transaction fee model. This allowed our sales team to rapidly increase the amount of companies we enrolled in our application.

Our first version of the application started to show signs of not being optimally adapted given all the new information we'd collected from our customers. So we were working on revamping it with an improved design and user experience with a dedicated UI/UX team.

The Improved Version of the Application

We launched the revamped version of our app (this time without a hard deadline) and the reception was great. This is when I started to feel like we actually launched a real product and not a MVP to validate a need.

You could now see the part directly on the platform (we've used xeogl for that)!

The sales of our product increased dramatically as the user interface was great and the experience made sense to prospective users. We went on to do some more major refactoring and clearing up technical debt.

We knew that the added load on our platform meant that we needed to have something cleaner to work with. This was important as technical debt will always creep up and you can't just always build features.

We were slowly emerging from the bootstrapping phase of the company to more serious territory and it felt great. We made some more hires in the customer care and the marketing side. We improved month after month how the company operated.

Around that time, we decided to implement two systems that would improve our productivity:

Objective and Key Result system: This really switched our whole mindset from working long hours to working on objective attainment. By having concrete goals that would improve how the company was doing, it allowed everyone to focus on what really mattered.

It also allowed us to stop tracking when people were working or when they were taking vacations. As long as the objectives were worked on, it didn't really matter what the employees' workflows were (as long as they were not overworking).

EOS System from Traction: This system was a very good foundational system to ensure that everyone stayed aligned. It really improved how our meetings were structured and laid the foundations for the vision of the company.

I used to scoff at the thought of having a vision or core values. But after reading the book and implementing it, I cannot understand how we got as far as we got without one.

This aligned everyone to a level that we didn't think possible and allowed us founders to make better decisions for the company.

It now felt that we were really running at a solid pace. Every month we had major improvements or good news in the company. The whole startup thing felt easier and was more enjoyable.

What I Learned From My Second Product Launch

I learned another good set of lessons during the time of the launch:

Your job as a founder is to "elevate and delegate". At a certain point, if you are still working on the minutiae of the work you are wasting resources.

It is usually way more cost effective to hire someone else that is more competent than you to do the operational work and to move on to another position that doesn't have staffing.

By de-risking and laying the groundwork for a section of the company that is weak you are ensuring that it's worthwhile to hire someone and that this person has something to start with. This is priceless.

No one can work 80 hours a week on different job types effectively. We realized this when we were looking at what the weakest points of the company were. It was always the spot where someone that had 3 different hats was working because there wasn't enough time to do quality work.

If you are working on 3 different positions as a founder and you work 80 hours per week, it is the equivalent of working as a tired part time worker. The documentation will be poor, the process will be non-existent, and mistakes will start to show up.

As soon as we saw someone work more than 40h a week it was a big red flag that we needed to distribute the load onto someone else.

Part-time and volunteer workers are usually a waste of time. Once we were picking up more speed, we found ourselves constantly waiting for the part-time worker or the volunteer to finish their part of the work. This was holding us back so we made it a policy to not hire part time workers again.

It's different for interns though, as they have a well contained work arrangement. For instance, we currently have 3 interns working on various machine learning projects as part of their PhD. This is perfect because the work that is given to them is well balanced and we know what to expect.

Around the time of the new platform release, we started our first accelerator programs.

The NEXT AI and EcoFuel Accelerators

I didn't really know what an accelerator was at that time. However by being in two I quickly understood the difference between an accelerator and an incubator.

An accelerator's job is to give tools to an already up and running startup to accelerate their growth. On the other hand, an incubator is where startups usually begin.

One thing that is very useful in accelerators is that they provide startups they select with funding. By doing the NEXTAI and EcoFuel accelerators we were able to get $100,000 in total funding!

It was way more fast-paced than the incubator we'd been in. We had virtual classes with incredible entrepreneurs and got technical classes with researchers in machine learning such as Yoshua Bengio.

We also got to meet other amazing tech entrepreneurs living similar challenges in trying to get a startup to scale during a pandemic.

Here we are keeping the 2m distance for a photo shoot.

It's at that time that we officially founded the more "research-y" side of the company that dealt with making AI models and working on the data we collected. We staffed that section of the company with PhD students and graduate master's students (and me!).

It's also at that time that we decided to raise our seed round of venture capital (VC) funding. We made this decision because we knew that we had something great, however we were in the type of business where we needed to scale fast to deliver the most value to our customers.

The more people use the platform, the more valuable it is for the people using it. Therefore, getting funding to crank up the sales and marketing is a must. We put our CEO on that full time as it is indeed a full-time job.

Around the time when NEXT AI was ending, we had one of our first major financial drawbacks that would forever change the way we saw failure in our company.

We thought that, just like at Centech, we were in a very good position to get the financing that comes at the very end of the program. However, we were in the finalists but not in the top 3 winner startup.

This was a major blow as we thought we were very solid during the whole program.

After gathering more information about why we weren't shortlisted, we realized that there was a major communication gap between what the organizers of the program thought we were doing and what we were doing.

They didn't realize how advanced our product was and were not aware of all the cool AI modules we were building to complement our offering.

What I Learned From Our First Startup Accelerator

This is where we realized a very, very important lesson:

Other people's perception of your startup is as (if not more) important than what you are actually doing. We couldn't blame the program organizer for having the wrong perception about our company when they weren't even aware of most of what was happening with our company in the first place.

There was so much cool stuff happening everyday, but the number of things we publicly showed was thin in comparison.

This was problematic and could seriously handicap ourselves in the future. This is when I made the decision to celebrate the wins of the company publicly.

Every release of the product, I would publicly acknowledge my team's work on our social media. If we were passing major sales milestones, I would make a statement out of that. A major advance in the AI research of the company would be public within the week that it happened.

I used to hate posting on social media as it felt like I was bragging, but it was one of the most important change we've made so far. By celebrating our wins publicly, we've increased by a lot the likelihood of good opportunities coming our way. This is now a vital part of the company that we leverage every day.

With our new understanding of how to best promote the company and improve our probability of success, we applied to two other bigger accelerators (Creative Destruction Lab and MaRS) and got accepted!

The Current State of the Company

This last week of February was the best week the company has had, by far. User activity is way up and the amount of people involved in our project hasn't stopped growing. We are also in the final stretch of closing our financing round, which will allow us to accelerate our growth by a large margin.

However, it's not like it's all good and there is nothing to do now. One of the curses of starting to learn about a topic and making improvements in the way you work is realizing how much there is still to improve.

My company-improvement list on Trello never gets any shorter. Every time I finish a book, I have twenty new improvement ideas and every time I talk to a mentor, I have a dozen more. Even when I finish the implementation of one improvement, I have three more that spawn.

It's very comforting, though, to know that all of the work you put to improve yourself and your startup pays off. Also, realizing that you have created a company that can provide for other human beings is amazing.

I've made a lot of efforts to shed our old prototypical startup way of thinking. This means the following:

There Are Unlimited Vacations for All Employees

This basically means that we don't track anyone's time off. The only time I'm talking to an employee regarding vacation is when I feel they don't take enough time off.

There Are No Working Hours.

If an employee wants to work early morning or late evening, I don't really care (because I do too). As long as the objectives are reasonably met, there is nothing worthwhile to track.

There is No Bragging about the Amount of Work Someone Piles Up Allowed.

It doesn't matter. Only objectives matter. If someone is working an unusual amount of hours, we flag that to the human relations department and we initiate a proposal to find more personnel.

We Invest in Our Employees

We invest in them by buying books, courses, conference tickets, certifications or finding them mentors. Learning is a crucial part of the company's culture and it is heavily promoted. It's also very great for me because I can buy all the books I want on Amazon!

In short, I'm trying to build a company which I would have enjoyed working for. This is one of the guiding principles behind the choices I've made along the way and it really created something that I'm proud of.

My Advice to Aspiring SaaS Entrepreneurs

So that's how I ended up becoming the CTO of my company that has 20+ employees, all from doing random hackathons. It's been a wild ride and still is, but I would not trade this for any other job.

I want to conclude this section with a list of advice and tips for tech entrepreneurs (SaaS in particular) that I've learned along the way. I broke it down into subsections for convenience.

General Product Advice

Your Product is Way Less Important Than You Think

The value the customer can get from your product is what matters. If you can deliver the same amount of value to your customer in a simpler way than having a full blown application, do it.

You will learn faster and you will be able to create more value for your customers in return. At some point though, the only way to keep increasing the value you can deliver is to have a good application. At that point you should have a very good idea about what is important to put in it.

Validate the Need for the Product Before Thinking About a Solution

Spending time and effort on an application that your customers don't care about is the biggest waste of time you can have.

Validate with them every step of the way to see whether or not what you are doing is useful. Even at the expense of development time.

The Tech Stack you Choose is Less Important Than you Think

The most important concern is if you have enough knowledge to build something with the tech you choose, and if you can safely hire people to work with it.

Spending time finding the most optimal stack to work with is oftentimes pointless.

Do not Overcomplicate Your Application at First

Start with a good old monolith and gradually refactor it when needed. The monolith architecture will work like a charm for longer than you think!

Put the Minimum Amount of Features in Your App to Generate the Maximum Amount of Values for Your Customers

The fewer features you have, the less maintenance, fewer bugs, and less technical debt you will accumulate. If a feature is not used by your users, kill it and scrub it from your code base.

Talk to Your Customers

Spend as much time as possible with them and really learn from them. The knowledge you will gain will be a major competitive edge and will allow you to always deliver value to them!

At Some Point CI/CD and a Good Suite of Tests is a Lifesaver.

Not having to fiddle around with deployment and not having to worry as much that you introduced a regression in your code is liberating.

It allows you to become more productive and have a better understanding of the whole code base when you have to read test errors.

Monitoring is Super Important and Should be Implemented as Soon as Possible

Being able to know what is being used, what is the state of the application, and if there are potential problems is a must.

Not having monitoring tools is like driving in a forest road at night with your sunglasses on. It's a bit weird and generally not a safe way to get wherever you want to go.

DO NOT OUTSOURCE YOUR CORE COMPETENCY.

This advice is in all caps because I'm yelling it. If the core of your business is making a web app, make sure that you have everything you need in-house to make a web app.

Relying on outsourcing firms that don't have direct access to your customers or your reality is a sure way to mess the whole thing up. It's therefore extra important that you define clearly what is your core competency in order to not outsource it.

Artificial Intelligence Advice

AI is Great, but Delivering Value to Your Customers is Better

If you don't need AI to deliver value to your customers, don't put AI in what you give them. It will slow you down big time. However, if you validated that you indeed need some sort of AI to provide value to your customers, make that a top priority for your company.

Ensure That You are Collecting the Right Data for Your AI

This is especially important if you are working with partnering organizations as they often have no idea what is good data for a given problem. You need to figure out if the data is great for the problem you are tackling before getting more of it.

Start With a Linear Regression and Work Your Way to That Deep Neural Network with Thousands of Layers

Even if you have tasks for which you have enough data to attempt larger models, start with the simple ones. It will allow for rapid feedback on your data and will help you secure some baseline performance that can be used as benchmarks for the larger models.

Iteratively Improve your AI system and Don't Wait Until Everything is Perfect to Launch.

It's fine to label an AI system as Beta and start experimenting at a larger scale with users. This applies to any product you build, but I feel like this is worth mentioning again in the AI context as it is often forgotten.

Company Advice

Join an Incubator

The amount of coaching you will get – even from the judges before being accepted – is very important. They've seen thousands of startup ideas and they will be able to give you some very valuable advice.

Incubators are oftentimes paid by the government for every startup that they get in their program, which means it's a win-win situation for everyone.

Join an Accelerator After Joining an Incubator

This gives you additional resources and allows you to get very good coaching on very specialized parts of your business (like machine learning or financing). It is also a very good way to network!

Setup Your Core Values and Your Vision for Your Company

Having a vision is like a superpower. As soon as someone throws in that blockchain idea for the nth time you can throw it right back by saying that it doesn't fit the vision.

If someone has a rotten attitude you can easily show your core values publicly and correct course. The hiring and firing is much easier when all of this is setup and understood by the whole company.

Document Your Company's Processes as Soon as Possible

You will be surprised by how much processes you have even at an early stage. You will also be surprised by how little everyone is aware of it (including yourself!).

By documenting these processes you will be in very good shape to start improving and refining them to increase everyone productivity.

You Most Likely Don't Need an Office

If you are building a SaaS product, your stuff will most likely live on the cloud and your offerings will be purely software-based. Learn about how to setup a remote work environment efficiently and save on the office cost early on!

Meetings are Less Important Than You Think

Face to face synchronous meetings are not that useful. I've found that most of the time, just having a Google document that says what problem you want to fix in the meeting and distributing it to people you want to meet with is 99% of the job.

You will get a few comments on what to change, 3-4 asynchronous back-and-forth discussions, and voilà! Another problem fixed.

Meetings are Sometimes Necessary

No meetings whatsoever are not possible, though (I'm a hardcore asynchronous guy and even I need to admit that). If after sending that document you have 30 comments and you get to a stalemate kind of situation, it's usually time to ring the meeting bell and address the point of contention synchronously.

Most of the time, it's a matter of miscommunication. Having this synchronous back and forth allows the issue(s) to be resolved more efficiently.

Make Most Stuff in Your Company Public to All Employees

If something that is work related doesn't have to be private to a specific set of people, it should be public. By having the opportunity to jump in someone else's operational discussion, you can provide much needed feedback that will save lots of time.

Also, by having this whole bank of general knowledge available to everyone, you ensure that people are all aware about what is going on in the other departments.

Make Sure that the Private Stuff Stays Private

This goes both for security-related sensitive material and for private employee matters. If an employee tells you something personal, do not break that trust.

Continuously Improve Your Company's Structure

A company is an ever-growing organism. The structure that is best for today won't necessarily be the best in a month's time. It needs to be continuously tweaked and improved in order to maximize the work that the people working on it can output.

Beware of Working with Large Entities Like Cities, Multinationals, or Governments

These are slow and could end up suffocating your company. They will book meetings upon meetings to move the project forward by inches. Even if they pay you a lot, the cycle of learning you can do with them is so long that you will not have improved by much.

Working with smaller entities allows for more direct feedback. And if you can gather enough of them you can have a much more robust business. Resting on a thousand small pillars is more stable than resting on two huge ones.

Employee Advice:

Don't Hire Jerks Just Because of their Technical Skills

It's a big no-no. If you think about it this way, a person will stifle the productivity of everyone by souring the cultural soup.

If people are dreading going to work because of that one person, you will end up with more problems than what this person can fix with their code.

Cultural Fit is not an Option

Clearly check if the person has the technical abilities that you are looking for. However, check just as rigorously if the person as the right personality for your company.

Having someone clash with the company or not upholding one of your core values will do more harm than good.

Team Fit is not an Option

Make the teams an integral part of the hiring process. You will be surprised by how picky the team is and how rigorous they are in the hiring process.

It happened quite often that the person we were interviewing passed the technical interview and the cultural one, but didn't pass the team interview.

The rationale for rejecting a participant from the team was always valid and we couldn't believe we didn't catch it earlier in the process.

Neurodiversity Increases Productivity

You have to resist the urge to hire people that think exactly like you if you want to have a truly productive company.

By having people from different backgrounds, you will increase the chance of finding creative ways out of problems and you will reduce your blind spots by a lot.

Don't Try to Fit a Good Profile in the Company, Find a Good Profile for a Need

Always start by assessing what is your most urgent need and then find the best person to fill that position. By starting the other way, you will bloat your company with people that don't truly create value.

You Will Have to Fire People and it's for the Best

I've had to let a few people in the company go, and every time it was better for all parties. However, do it with respect. If you did all the work to bring someone on your ship, you should do all the work to bring someone out of it.

This means ensuring that this person understands why it's not a fit, that you gave enough warning signs, and making sure that this person has the support they need once they are moving away from the company.

Make Sure That Your Employees are Genuinely Happy

If someone doesn't feel good, talk to them and help them out. Wish them a happy birthday. Say thank you when they do something great. Coach them when they want to grow. Debug them when they make a mistake.

Having happy employees is one of your most valuable currencies as a startup and what makes working in one such a great experience.

Personal Advice:

Make Sure that the Founders or Executives don't Kill Each Other – and the Company

What do you get when you have a toxic startup culture of working insane work hours coupled with financial stress and customer problems? A good recipe for company failure.

Make sure to always reserve at least one hour per week where you don't talk about the company, but just check on each other and try to mend personal issues in the open.

Repeat After me: It's 👏 a 👏 Marathon 👏 not 👏 a 👏 Sprint

Insane working conditions cannot last. It's not if you will burn out, it's when.

If you cannot envision keeping the pace of work you currently have for the rest of your life, change it before it's too late.

I've seen too many startups crumble suddenly because of people thinking they can sustain having no time off forever.

Leave Room for Your Personal Growth

Learn about that one topic that is completely left field for your startup and enjoy it. Go ahead and network with people for your own benefit, it's okay. The more you grow as a person the higher the potential growth for your company.

Leave Room to Just Chill Out

Even if you enjoy working on your startup don't neglect the other aspects of your life.

It's fine to have other friends outside of work and it's fine to just unplug for a while. If you can't do that you have serious issue to fix in your company.

Have Fun

It's genuinely fun to build a company from the ground up. Enjoy the time working on that nasty bug that put the whole EC2 instance down. Enjoy your time calling this one customer that has nothing good to say about what you do.

Enjoy all of the little problems that will pave the way of your company. Because a startup can only do two thing: Die, in which case you will look back at those days with fond memory. Grow, in which case it will start to become something bigger than you and gain a personality of its own!

Useful (SaaS) Entrepreneurship Reading

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses:

This book is a very simple read and taught me that cycling through hypothesis/learning is way more important than doing the most perfect thing right off the bat.

As a technical person that loves technology, I couldn’t understand why the tech was not at the forefront of every business discussion.

This book, with the clear example of bold tests that were done with real users, showed me exactly why a focus on building a product before understanding what the users will think of the product is a bad idea.

Traction: Get a Grip on Your Business

This book helped me make sense of how to structure our company once it has scaled past the founders. I’m at something like the sixth read cover to cover.

There is a lot of useful information and practical guidelines to use in order to really get a solid structure that make sense for the next growth phase.

It also helped create a sense of calm when thinking about the future because it increases your awareness of what will come in the future.

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

I read this book before reading Traction, however there are a lot of similarities between the OKR goal structure and the Rock goal structure from Traction. The basic idea is that you have limited time to work on goals/projects, so work on the most impactful ones and ditch the rest.

The idea of simply not thinking about the low priority objectives really creates a sense of space in your head. Knowing exactly what to focus on and having the liberty to think about how to get there also helped create an ultra-collaborative structure.

I use the OKR system in my personal life too. It really helps me reassure myself that I’m on the right path and allow me to say no to opportunities that pop up throughout year that are not aligned with my objectives.

Peopleware: Productive Projects and Teams

This was a very enjoyable read. It talks about a facet of software engineering that is often not taken into consideration, which is the people factor. I absolutely love the straight to the point organic writing style that the authors use.

Lots of examples are given and there is a significant supplementation of statistics along their argumentation that really help gauge what non conventional changes to implement.

DRIVE: The surprising truth about what motivates us

Drive is very closely related to Peopleware in the subject it addresses. Both of them help in figuring out how to create a work environment that is purposeful and that drive people to give their fullest.

I’ve learned a great deal about how much “carrot and stick” kind of reward/punishment comes into play in the traditional workplace and how it's not the optimal way to increase motivation.

It also allowed me to understand how I can push myself to accomplish my goals in a purposeful manner without having to bribe and trick myself.

Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

This book is an extensive introduction to DevOps culture and is a good handbook to keep to consult when you're unsure about a certain aspect or situation.

It was the book that introduced me in more depth to that way of thinking and got me to really understand it more than on the surface level. It had some very neat examples of how all of the DevOps concepts tie up in the real world.

However, it’s quite a lengthy book. It is meant to be consulted in a non-linear fashion. I recommend keeping a copy at hand if you manage a technological team to get some ideas about what to do in a given situation.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

I read the Phoenix Project a while after having read Effective DevOps. Effective DevOps gave me a deeper understanding of the movement, but it’s the Phoenix Project that really made everything “click”.

It’s a novel, but explained in such an organic way that it could have been a biography. I read the whole thing in 2 days over the summer as I was very engaged with the protagonist's struggle with inefficient process and “impossible” goals to meet.

After reading it I felt way more confident that the changes I was making to my organization were the right ones.

If I had one book to give to a non-tech manager to make them understand how to make a tech department fail and how to make it thrive, it would be this one.

Designing Data-Intensive Applications

This book was so densely packed with information gained from working with very difficult problems that you probably need to re-read it from time to time while you also work on difficult problems.

I’ve learned a lot, both in the inner design of the behemoth of the internet and how much these behemoths were built by facing a constant stream of problems.

The sheer amount of tradeoffs, learning, and ambiguity that takes place in systems at huge scale was staggering. It helped me prepare and better react when I hit various problems in my tiny (in comparison) systems I’d been building.

Likewise, this is the kind of book that should be read periodically while building something that is in the process of scaling.

Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

This book is one that really helped me better structure our remote company so we could hit our business objectives and help our employees feel productive and happy.

I drew a lot of inspiration from how open source projects were structured and made quite a lot of changes in that sense. It also helped me understand and appreciate a bit more about how open source projects work.

Principles by Ray Dalio

This is an incredible book with an insane amount of tips from a successful entrepreneur in the financial sector.

The amount of useful content in there is staggering and will require multiple reads in order to extract it all. If you are looking for new ideas to make your organization more efficient, better at problem solving, or stimulate growth, it's a must!

Delivering Happiness: A Path to Profits, Passion, and Purpose

A very beautiful book by the late CEO of Zappos. It's a humble book filled with good learning and takeaways by Tony Hsieh in his entrepreneurial journey.

The most important part here is the focus on making sure that the culture was right, as he had two main company successes in his career: One with LinkExchange that had no focus on the culture and another one with Zappos which was heavily invested in it.

The latter is arguably the stronger business.

Reaching Out

If you are interested in learning more about my company, you can check our website. If you have questions feel free to add me on LinkedIn or Twitter to chat :)

I hope this was helpful!

In this article, I'll share my experience and the lessons I learned attending (and winning) my first hackathon (spoiler alert: you're not actually hacking anything...😁).

One of the reasons I love the world of design so much is that its constant evolution requires you to maintain a growth mindset. You always have to be eager to upskill or explore a new craft. And as someone who finds great fulfillment in a meaningful challenge, this works especially well for me.

And so I put it to the test: I humbly signed up for my first hackathon, only moderately aware of what such an event entails. I was even less certain of what valuable contributions I could bring to the table as a (very) Junior UX Designer. Challenge accepted.

The first hurdle was finding a hackathon to participate in in the first place. I was overwhelmed by the number of choices out there, and found that a majority of hackathons were for students-only. This left university graduates and current bootcamp students like myself in a gray area.

Nonetheless, I set my sights on the more inclusive and social cause-driven events I could find, and reached out to the organizers to confirm my eligibility after applying.

A few exchanges later, I was accepted into DubHacks, the largest 24-hour hackathon in the Pacific Northwest.

After putting my imposter syndrome aside, forming a team, and getting through an exhaustive 24 hours, my team’s project went on to win the Best Use for Social Good category. Here are some things I learned from the experience.

via GIPHY

Why Every Hackathon Team Needs a Designer

I’m pleased to report that what you’ve heard many times over in design school or in tutorials is true: not everyone thinks like a designer.

My team consisted of brilliant developers who were able to quickly deduce how to use their knowledge to build a software tool, but were less well-versed on how to build a viable product.

A good designer knows that a product is not merely the sum of its parts, but is a coherent and cohesive experience — this is exactly the unique perspective a designer brings to the table at a hackathon.

As a designer on the team, it’s your job to look beyond what you're building on a mechanical level, and constantly direct the team towards the greater, more human level of what you’re creating.

Yes, the framework and the tech stack are vital, but what good is the greatest technology if it’s unusable (or unclear) to the people who need it most?

Whenever our product’s positioning started to feel too broad or unfocused, I’d do my best to reign it in, reminding the team who we were building for, what our primary use cases were, and what problem we were trying to solve.

What the Designer Does on a Hackathon Team

If you’re a designer who wants to participate in a hackathon and you aren’t sure what deliverables or actionable steps you should take throughout the process (like I was), here’s an overview of what my involvement looked like.

Landscape Analysis

This is a crucial aspect of your hackathon project that shouldn’t be overlooked. Your project will not only be judged by its execution, but also its viability — what problem is it solving? Which users does it help? How do you know this?

This is a great chance to tap into your Design Thinking process and get to the root of the problem you’re building a solution for.

For me, this involved doing extensive research into the issues surrounding our chosen problem area, as well as the existing tools in the market that aim to solve similar (or different) issues.

I also snuck in some user research by reaching out to relevant acquaintances for short, informal user interviews to gain a better idea of their experience and pain points in this area.

This was an invaluable step in our process. When it came time to present our project, we not only had a minimum viable product to showcase, but the research to validate the need for our product in the first place.

I took a deep dive into the world of web inequity for those with vision impairments and limited broadband

Task Flows and Sketches

Due to the rushed and scrappy nature of hackathons, your finished project will not be fully fleshed out. This means it’s important to at least include the most essential features.

Creating your product’s primary task flow(s) helps the developers jump right into working on the most important functions first. This is especially helpful if your team ends up not being able to complete the development of your other task flows by the submission deadline.

Rough sketches of what the interface will look like help developers contextualize what they’re building from the start and provide important constraints, however loose.

These were the first deliverables I sent to my team when the hackathon began. I explained to them the main task(s) we should aim to develop, and walked through my sketches of the interface, making note of the most important components on each screen (mainly our CTAs).

The basic task flows that our product would need to include

Wireframes and MockUps

Wireframes take your rough sketches one step further and give your developers even more important constraints to work with. Using tools like Figma or Zepplin to share your designs with your developers makes the best use of your time, as they can inspect and use the corresponding code.

Adding high fidelity mockups in your presentation helps showcase your work and make it feel more real/functional than your MVP, which will most likely look like your low-fidelity wireframes.

My team didn’t officially start coding the front-end of our product until I sent them low-fidelity wireframes. After I shared the designs for the main interfaces, I spent a lot of time designing multiple screens and high-fidelity wireframes that we never would have had time to develop.

Instead, I’d recommend focusing on the main interface(s) your devs will be building, and then flesh out a high-fidelity version for the purposes of your mockup and presentation.

To showcase the design in our presentation, I placed a PNG mockup of our product’s landing page in a device (using a Figma Community file template), as well as an additional short promo video I made using Rotato.

My low-fi wireframes, most of which did not see the light of day outside my Figma file

Project Management and Presentation

As a designer, you have a holistic perspective on what your team is trying to build beyond the code. Coupled with the landscape research you conducted, this lends perfectly to taking the lead on building your team’s final presentation.

Your presentation is the “big sell” of your project — without it, your product has no context, and can’t be judged by the panel. Your presentation doesn’t need to be immaculately designed in and of itself, but should include a few key points, such as:

• An introduction to your hack and team members
• The problem you’re trying to solve
• Your user base and business use cases, and how your product solves for these problems
• Tech stack and product features
• Long term impact of your product
• Difficulties and complications you encountered, and what you learned along the way

I built our presentation in Canva, which allows for easy collaboration and embedded media.

Designers have the unique advantage of not being pigeon-holed into one sole workflow during hackathons, which allows you to move your team along if/when they’re getting lost in code.

This establishes important time limits and constraints, and helps make sure you distribute your time and tasks efficiently.

Throughout the 24-hour event, I reminded my team of our upcoming deadlines: what time we should have our MVP finalized, when we would start practicing our presentation, and our submission deadline. I left sufficient buffer room for each in case anything went wrong or got delayed (which, in the world of hackathons, is a near guarantee).

via GIPHY

Where Empathy Meets Strategy

Our project idea was born out of my passion for making the web more accessible for people with disabilities and limited access to the internet.

I strongly believe design (and tech) is a tool with which we can dismantle exclusionary systems in favor for more inclusive ones. And this commitment to serving underrepresented groups fueled our work throughout the event.

I was lucky to be on a team with a member who already had some hackathon experience which allowed us to streamline our process. But looking back, there were other clear steps we took which contributed to our win in the Best Use for Social Good category.

Here’s my short list of tips to keep in mind to conquer your first (or any) hackathon experience as a designer:

1. Start Early

I don’t mean that you should begin any actual hacking earlier than the event start time, of course. But I do suggest getting to know your team, synthesizing some project ideas, and coming up with an action plan before the hackathon actually begins.

Our team hopped on a Google Doc one week before the hackathon to list out each of our core skills and propose 2 project ideas for us to later vote on.

Before the hackathon even started, we already had a good idea of who our team members were, what we were good at, and what we’d be building in the 24 hour timeframe.

2. Do your research

I can't overstate the importance of research in your process. It not only helps you reach your problem statement and validate the world's need for your project, but also serves as a reminder during the more daunting hours of the event what impact you’re hoping to make.

In moments of insecurity, I’d look back at the research I’d done in this problem space, remind myself of the quantifiable need for a solution, and use that as fuel to keep pushing.

3. Be Agile

I learned pretty quickly that, perhaps unsurprisingly, building a minimum viable product from scratch in a short amount of time gets messy. Not everything you set out to build in the beginning of the hackathon will make it into the final design, and that’s okay.

This is a great environment to be scrappy, fail fast, iterate, and streamline your workflow as much as possible.

4. Communicate clearly and frequently

Our team communicated mainly via Facebook Messenger, where the developers could quickly troubleshoot and bounce ideas off each other.

I used that communication channel to keep the team updated on what I was working on, make some UI notes, ask if anyone needed me for anything.

I also used it to remind the team of what I needed from them, be it some tech copy to put into our presentation or a reminder of the hour deadline we agreed to start reviewing our project by.

5. Be passionate

The cliche is not lost on me, either, but it’s true. Even your dream design job may come with some projects you’re not super excited about.

Hackathons, on the other hand, provide the unique opportunity to build something you exclusively excited about, under no obligation other than your own will.

Whether it's a social cause or a creative technology, finding a project you’re deeply passionate about will help guide, sustain, and validate your work from beginning to end.

via GIPHY

TL;DR: Get out there and be great

I hope this guide serves both as a framework for the seasoned designer to help structure your workflow during a hackathon, and as inspiration for the young designer to participate in the crazy, chaotic, thrilling, and rewarding world of hackathons head-on.

Had I let my fear and intimidation get the best of me, I would have missed out on a tremendous learning opportunity. Beyond design deliverables, my first hackathon experience allowed me to practice my communication skills, work closely with developers and find a common language between us to help progress our work, and become comfortable working under tight timelines and constraints.

These are all skills that are invaluable to a designer on any level, but they're especially insightful for a junior in the field who may not yet have ample opportunities to learn by doing.

So I encourage any and every designer reading this to be brave and be great — I’ll be cheering you on.

In 2016 I was looking for an online coding bootcamp. I wanted on that would allow me to keep my full-time job at the time as a Web Developer and Designer, but at the same time help me bring my skills as a Full Stack Developer up to date.

Diving into the tech community

After a lot of research, I found freeCodeCamp, an online coding program, and I started to work on the Curriculum and projects for the Certifications.

This exciting adventure helped me, in 2018, make the decision to start my remote freelance career and dedicate more time to completing the projects for the last certifications on freeCodeCamp.

I started to attend local Meetups to meet other developers and share the same passion for coding. But there was something more that I wanted to peruse: a Hackathon. When FreeCodeCamp announced the online Hackathon in 2018, I just jumped in. Although that was my first experience and my team didn’t win any prizes, I decided to find other Hackathons in my area to repeat the experience.

Hackathons give you that kind of energy that you can’t explain to others. You get to work for 24 hours with a team you met a few minutes before and get to create wonderful projects.

When I found that there was Hack Upstate XIII organized in my area, I didn’t think twice and I signed up right away. I waited impatiently every day for the big day to come.

Hack Upstate XIII (Source: Jesse Peplinski, 2019)

In the meantime, the more you look around the more you see stuff you never saw before. I discovered Albany Can Code, a local coding bootcamp that has Front End and Back End Developer classes. I joined to fulfill my dream to go back to college at least in a different sort of way.

I remember that everything happened so fast in my life that in no time I was doing everything I loved. I had a remote career that allowed me to work my own hours and study to get my certifications. I got the chance to work with a team of classmates in projects using Scrum as an Agile environment. The first projects for graduation were individual projects but the last projects were team projects.

During the class, we went from React Hooks — a hot topic — to React Native just a few weeks before the Hackathon. We worked on a few small projects, nothing fancy. Our instructors introduced us to Expo.io and the particulars of React Native that differentiate it from React.

Time was going by so fast, and I got involved more and more in coding meetups. One situation brings another one, and I was asked to teach Flutter at Google Developer Group of Capital Region. Shortly after I got nominated as a Women Techmakers Ambassador for the same chapter (Capital Region).

In the meantime, my freelance business started to grow. I was working on a few projects that gave me time to attend my coding bootcamp and organize the Google Developer Group CodeLabs and StudyJams though the Meetup Group.

I started to find myself so busy in all kind of activities that I found it difficult to take in more.

The Hackathon

The day before my Hackathon I just had time to pack some stuff I needed for the 48 hours I would be away from home. My husband supported every single decision of mine and made it easier on me to be part of all this craziness.

I arrived at the Hackathon and I had to find a team to join. I hoped to find a project that I could contribute to.

Finding a team

I only knew one girl that I met few weeks before that was going to go to the Hackathon. I was hoping to make a team with her, but when we came in I couldn’t find her in the crowd. The opening ceremony started and I was getting nervous because I didn’t have a team yet and they were already presenting the projects.

I had few chances to find a team before the ceremony, when I heard someone saying that they needed a Graphic and Web Designer. So I introduced myself and suggested that we could form a team. I found out that they were companies looking for talent and they asked me to contact them after the competition. That was nice because I am always open to joining a remote team to work as a Full Stack Developer no matter if in the Front End or the Back-End.

Listening to all the great ideas the groups were putting on the table I was thinking that I might need to work alone on a project. I figured I’d better start to coming up with some ideas.

All of a sudden I heard one of the last groups presenting say that they were looking for a Designer, since they had all the other parts of the team already formed. I didn’t even hear very well what they were going to work on, and everyone started to walk away from the room to find a spot to start to code.

I ran after the two guys that presented their project and introduced myself and told them that I was a Designer and I could join their team. We agreed and we headed to the office area to find a spot for us. We started all to talk about the project we would develop and which of the API’s in the competition we would use.

The tech

I was really hoping to work on a React project since I had some experience with projects I worked on for freeCodeCamp and the Albany Can Code bootcamp. I got hit by a hammer when I heard we would be working on a React Native project — but no one knew React Native. Some guys knew React like I did, and they decided to take care of the Front End functionality that I was hoping to work on. Some other guys knew Python and they were taking care of the Back End using Heroku and a Raspberry Pi to host the server and connect it to the API.

We were going to build an app called Parking Assistant that makes parking easier for drivers in the city by solving two types of problems: 1) managing long-term street parking and 2) addressing crime risks in the immediate area of the parking location.

Demo of “Parking Assistant” that help you know where it’s safe to park your car. (Source: STAE, 2019)

Learning on the fly

I felt like I couldn’t breathe when I found out that I was supposed to take care of the React Native part. I didn’t know what to say. I proposed to the team that we use Expo.io to test our mobile app since I had some experience with it.

A few minutes later I was in front of a whiteboard making sketches of an app that I didn’t have any idea how to build. My team was making plans on how to break the process down into steps and distribute the work to be done between us.

Inside me, I was getting very nervous and found it difficult to concentrate. We finished making plans and deciding what everyone would do. We then started our own adventures and research. Somehow I didn’t pull myself out of this team and project — but I didn’t want to disappoint them and create a disaster.

The clock was ticking I was talking with the team asking questions and answering others to see how to coordinate our work. All the code I was writing was not working and I was not able to make much progress. I was reading the documentation because I knew that React Native is different than React. I was not using HTML and CSS for the Design part but had a different kind of approach that I needed first to get familiar with.

I got to build a very simple home page for our app with a title and a button and customize it. I made it answer the gestures using the React code that I was more familiar with. React Native was for sure a challenge and the 24 hours we had in our hands to build our app was not enough to get to know all the ins and outs of the language.

That was the first step and gave me more confidence in me. In class, we did some staff in React Native but nothing I needed for my app, so I was on my own.

Now I had to build a compass feature to use in the next component when clicking the button on the homepage. It was not easy, and even though it was getting late into the night we continued our work. After a while, I got to work the Compass and the complexity behind it. We integrated the code step by step one with another and moved over to the next step so we got to see progress and the app taking shape. I felt much better after completing this part of the mission.

Next on my list, I had to build a timer that would show to the user the time left until they needed to move their car to avoid a ticket. I found a library to use but it took me some time to figure out how to customize it. And even though I was following their instructions, it was not working the way I wanted it to work. At least I had the functionality we needed for the app, but I didn’t have too much time to play with it — we needed to add the component to the app so we could test the Compass and get the timer to work and get alerts as a result of using the API.

We started to test the app in the office by choosing points on the map near us and trying to point the compass the way it made sense to make the app work. But it didn’t work correctly.

We had to go out of the building on the street in the night to test the app. There were many things to overcome and work on after our testing. Other research and code debugging and so on. We were getting there and it was almost morning when all of us got some sleep in our sleeping bags on the floors all over the offices. Some people were from the area went home to sleep, lucky them! You couldn’t really sleep but just lying down and trying to close your eyes made you feel a little bit less exhausted. Our minds for sure would not shut off and would keep thinking of ideas to better our project.

After a while, all of our team got together and got to prepare a presentation. We made some slides, a video demo, and so on.

The hosts and the sponsors got us food and drinks for the whole time to get us to concentrate on our mission to deliver innovative projects.

How our hard work paid off

Everyone got ready to present the projects and we started to feel very good about our project and proud somehow. I was hoping in my heart to win at least a prize. The projects were one more innovative than the other, one more interesting than the other. It was not easy for the judges to decide and I got to like some of the projects in the competition myself. But I didn’t lose my focus. I came with the hope to build something but now I was confident and looking to win something.

The judges made their decision and silence came back in my mind and soul, my heart was beating slowly. All of the sudden I heard our app name: Parking Assistant won the Best Use of Stae’s API using a Syracuse Dataset prize. I was screaming inside my brain and threw my hands in the air and congratulated my team. As the list of prizes was getting smaller and smaller and nearer to the top and the Gran Prize, I heard again our app name. We won the First Runner-up prize! This time I started to scream from real from happiness.

It was not for the money, because we were a 7-person team — unusual for this kind of competition were the teams are between 2–5 or so people. The 2 prizes put together we had to divide between us, but we got to bring home $100 each. That was nice to have in our wallets, but the real joy was the fact that others appreciated our project.

The Parking Assistant hack team (Source: Jesse Peplinski, 2019)

How the Hackathon changed my life

When I got home I started to share our success with relatives, friends, colleagues and social networks. The feeling was great, and I saw people start to react to my posts not only on Facebook but on LinkedIn and Twitter also, which are more professional networks.

I turned back to my normal life to organize what I started before the Hackathon: a monthly Flutter Meetup Study Jam. I also celebrated International Women’s Day’19 with a fantastic group of women speakers and a conference room full of almost 50 women and men.

International Women’s Day Celebration (IWD’19) — Women Techmakers and GDG Capital Region

A few days later after the Hackathon, we got contacted by the Stae API staff to interview us about our experience working together on the project. It was nice to meet my team again, this time online. Everyone shared their experiences and future intentions related to our project.

The outcome of the Hackathon was that all of the sudden I got to talk with people more and I become more interested in the experience and my team winning a project at the Hackathon. Not to mention that I got to talk with businesses interested in working on great projects who wanted to get me involved.

I think all of us should consider participating at Hackathons online and in person. It gives you the opportunity to show the world the skills you’ve gained as a self-taught Developer, and your ability to work with a team that you just met to create fully functional and innovative products. Even for those that didn’t win a prize, they still created very interesting apps. We all interacted with them and had fun together, and we connected to work on new projects or open new startup businesses.

Also, before I finished writing this article for you, I got my invitation to the North America GDG Academy at the Google Boulder Office on July 12–13th.

Going out there to attend Meetups and organizing Codelabs and events dedicated to tech put me in contact with many businesses and developers in my community. All of this made my business grow, which would not have happened if I was sitting at my desk in my home office looking for new projects to work on. You get recommendations from people around you that you just met about new projects you can join. Things start to happen to you just by being in the right place at the right time.

So to all of you, I would like to say: get out there and change the world! Even if you think you can’t do it now, if you don’t try it you will never know the outcome. The whole world is waiting for your change and innovation!

Happy Hacking!

Using these strategies, you might even win…

I believe that many people have heard of the word — Hackathon. But what the heck is it?

What is a Hackathon?

A hackathon (also known as a hack day, hackfest or codefest) is a design sprint-like event in which computer programmers and others involved in software development, including graphic designers, interface designers, project managers, and others, often including domain experts, collaborate intensively on software projects. — Wikipedia

In layperson’s terms, a hackathon is usually a 24~72 hour long event. The organizer will provide some challenges, and the participants will form teams and try to come up with their best ideas/solutions.

Eventually, the team(s) who presented the best ideas/solutions will get to win some cool prizes. Prizes can be cash or some gadgets. The agenda usually goes like this:

1. Registration
2. Introduction
3. Team Formation
4. Start Hacking
5. Snacking (foods, snacks, midnight snacks, pizza…)
6. Hacking Ends
7. Presentations/Pitches & Judging
8. Winner Announced

Let’s begin our journey and learn how we can crack the hackathon!

1. Unity is strength

To win the hackathon, you have to form your dream team. The first thing to do when you get to a hackathon is to form a team. You will be forming a team with random people, and ideally, a 3~5 person team is good.

Often, you will find that people there are equipped with different expertise. Don’t be afraid if you can’t code because that is absolutely fine.

Your mission is to find these 3 types of people and ask them to join your team (would be great if you yourself are one of these 3 as well):

1. The Coder — You will need at least one person who can code. Someone with front-end or mobile development experience is even better. If your team doesn’t have a single person who can code, go find one.
2. The Presenter a.k.a. The Salesperson — If you are very confident in building a great product, good to hear that. Though, if you can’t sell it to the audience, I’m sorry to tell you that no matter how great your idea is, you will most likely fail. Someone who can present well is very important here. I would even say that sometimes the presenter is even more important than the coder.
3. The Designer — Now you have got someone who can code, someone who knows how to sell the idea, what’s next? You need someone who can make a nice user interface for the product. Although a designer is not a must, still, it is strongly recommended to have one in the team.

2. The message behind

Figure out what companies are looking for. Companies are not doing charity. After you have formed your team, calm down and observe. Look around and make sure you know who are the event sponsors.

For instance, hackathons organized by Microsoft probably will look for some ideas that can fully utilize Microsoft technology — Azure Machine Learning, SQL Database, Cognitive Services, etc.

Almost 100% of the time, the companies who sponsor the hackathon want to see how their products or services can be used to build the next Facebook or Snapchat. Thus, focus on thinking how you can make use of the services provided by the sponsors.

3. The light bulb moment

Brainstorm with your team and try to come up with a list of ideas. Any random idea is fine, just write it out and see which one makes the most sense.

There was once I went for a hackathon in London. It was organized by a company that provided mobile wallet and sponsored by another company that sells beacons.

We came up with an Android mobile app that allows people to order food in any restaurant easily. People can read the restaurant’s menu, order, pay with their phones, and just wait for the food to be served.

We had a database that stores information that looks somewhat like this — _<beacon_id, restaurant_table__id>

By putting a beacon on each of the tables in the restaurant, we can identify which restaurant a person is in, and also where the person is seated.

Knowing where the user is, our application can decide which menu to show to the user. After ordering, the user can make a payment using either the mobile wallet, credit cards, or cash.

As you can see, our application made use of both the service provided by the organizer — the mobile wallet, as well as the product given by the sponsor — the beacon. This is the kind of idea that can win you the hackathon.

If possible, we should always make use of as many services given as possible. Having said that, I’m not telling you that embedding all the services will win you the hackathon. But rather, if there are 2 ideas from different teams, both cool and innovative, the team that uses more services has a higher chance to win.

4. Let The Coder shine

Ask the coder in your team to start building a Proof-Of-Concept (POC). After coming up with a brilliant idea, make it real. This is the time where the coder and the designer have to work closely together.

A POC doesn’t have to be bug-free and it can actually have zero functionality. In fact, most of the time, more than 80% of the functions are hard-coded. It is just for visualization purposes, helping the audience understand how your product/idea works.

Although a POC doesn’t have to have all the functions, one important thing is that it must look good. Try to make it look really nice so that the judges can be impressed when they see your team coming up with such a beautifully designed product in a limited amount of time.

5. The Steve Jobs moment

Prepare for the presentation. Ideally, the salesperson can start working on the presentation while the POC is being built.

Sometimes, at least for me, the salesperson and the coder are the same person. In this case, work on the POC first, and depending on how much time you have left, you have to quickly decide which portions of your application need to be hard-coded.

I usually spend 2~3 hours preparing for the presentation. While preparing for my slides, I like to use the KISS principle — Keep It Simple Stupid.

Remember, we are not giving a lecture and we want people to buy our idea. We want people to listen to us. So always make your slides simple, the simpler the better.

You don’t have too much time. Thus, keep your presentation and slides concise. Here I’m going to tell you the secret (formula) on how to prepare for a 5 star presentation:

1. Problem statements — We want to solve some problems using technology. Prepare a few slides telling people about the background of the problem that you are trying to solve.
2. Demo — People get bored easily. After telling people what the problem is, straight away tell them how you are going to solve it. Quickly show them your demo and WOW them. (Please make sure your demo works!)
3. Compare — Do a comparison. Is there already an existing solution to the problem, if there is, how is your idea better?
4. Hidden Slides — Always prepare some hidden slides that discuss potential future enhancements of the idea, business model, and what are some difficulties you faced during the hackathon. These can be useful during the Q&A.

6. Prepare for the prize

Get yourself prepared for the prize. Of course t’s not guaranteed, but If you follow all the steps I mentioned above, most likely you will win something.

7. Some beginner’s mistakes

One beginner mistake would be:

Not having a Proof-Of-Concept (POC) that could be showcased during the presentation. Simple idea, just put yourself in the judges’ shoes. If you were the judge, would you prefer someone who could show you something, say a website or mobile app, or someone who could only verbally tell you what their idea was? Which one would you think is more convincing?

Another mistake that many people make, especially those who first join a hackathon — focussing too much on building a functional or bug-free application. It is undeniable that this is right while building a proper product, but unfortunately, it does not work for the hackathon. Hardcoding is allowed here!

And the last one, also the one that I think people neglect — not spending enough time preparing for the presentation. The presentation is the only chance where you can sell your idea to the judges, the only time you can tell them: “my(give) idea(me) is(the) brilliant(prize)!”. So, you should always spend more time preparing for your presentation.

8. One last thing

Don’t forget to say bye to your lovely teammates. Bring the prize home and take a long rest.

After you have had enough rest, don’t forget to come back to this story and give me some claps!

So, you’re looking for a way to spend your Saturday, and you come across the brilliant idea to go spend the entire day at an organized hackathon. Fun! But not necessarily. Like anything else, hackathons are something where you get out what you put in. But at least here, you typically are going to get free bagels, pizza and coffee for your trouble (if you have ever found a hackathon with a different menu…

After attending over 10 hackathons and winning 4 of them myself, here are a few common characteristics I observed in winners.

1. They solve a big problem

Now I know what you’re thinking, it sounds like the most repeated hackathon advice ever, but there’s a reason for that. Most hackathons have a real-world impact as a big judging criterion. This can be up to 25% of your total score. Would you pick a cat pictures platform (no matter how polished it might be) or a hack that changes the lives of its users?

To get an idea of what big problems look like, check these projects out:

Dubit — a video dubbing app for making education accessible to children from developing countries.

MLSI — a sign language interpreter for people who have hearing related problems.

TalkToMe — a virtual assistant for visually impaired Chrome users.

2. Have a demo that makes the judges go wow

In addition to having a big impact, you need a demo that shows the core functionality of the product. It’s even better if the audience can interact with it in some way themselves.

With my most successful hack Dubit, we were able to translate a YouTube video from a judge into their native language on the stage. It even got us a backstage chat with them because of it.

3. Spend 25% of the time on ideation — or better yet, try to have a few ideas before you come

It’s no secret that no matter how impressive the demo, your efforts don’t amount for much until they’re a well-formed and coherent idea. A lot of hackathons have API prizes that encourage you to use sponsor APIs and form ideas around them.

Most people don’t pay attention to smaller API prizes. That decreased competitiveness make these prizes easier to win. You have to plan correctly.

For example, BPatient is an NLP solution to search for symptoms in a disease database. It is a fairly common product. Yet, they were able to bag a prize because they utilized an obscure API to make it.

4. Sleep for 3–4 hours

While some people can get by without sleeping, I found that sleeping about 3–4 hours gave me the best balance between feeling fresh without spending too much time. While it might seem coincidental at first, most top teams I observed including my own weren’t coding all the time. As a developer, I found it helpful to sleep on a big bug and then, upon waking up, and I’d instantly solve it.

5. Don’t fret too much over design

Now, this is controversial for many reasons, but the context matters here. Having great design is always helpful. But if you have to choose between getting your core product functionality finished and improving on your design — I would pick core functionality 9/10 times.

6. Learn from others and have fun

Devpost has a great collection of hackathon projects from all big events. It is an amazing resource for inspiration and for looking at what other people are doing at these events.

Even though winning is definitely pleasant, hackathons are more than that. At my first hackathon, I couldn’t get my project done in time and had to go with a half-baked demo to present. I took that as a learning lesson and made it into one of my best projects after the hackathon was over. It’s important to know that at the very least, you’re learning something. You probably going home with some ideas and possibly a working prototype — and that is no less than a victory.

Question: What can you do with the following?

• Saturday + Sunday
• 16 hours of brainstorm, design, and dev time
• 4 strangers who met at breakfast on Saturday morning
• Hacking space, free food, and a slew of hackathon goodies from the organizers of the freeCodeCamp/Netlify JAMstack 2018 Hackathon hosted at GitHub

Answer: A functional live “Game Show” application on the web.

• Built on the backs of at least 18 significant free pieces of software (conservative estimate)
• About 80 concurrent players in the live final demo
• $4 total expenses (for a domain name)
• One $500 grand prize from among the 28 teams and hundreds of participants with submissions

The final pitch for WITWorld by team Where In The World:

“Game show” web application that presents curated photos of images from somewhere in the world to a live, participating audience. In each game, the audience is asked to pin the location where the photo was taken on a map. The closer a player is to the actual location, the higher on the leaderboard they place.

See the repository here.

The term “static site” comes with a lot of baggage. It feels like a relic of the early days of the internet, when static web pages were considered to “display the same information for all users, from all contexts” — phrasing that still sits on Wikipedia’s Static web page entry as of this writing.

So when we say that the fundamental foundation of a JAMstack application is that it is centered around a static website, that’s sure to raise a lot of eyebrows. After all, the personalized, information-laden nature of today’s web seems to suggest that static web pages are non-starters.

That mindset has led to a proliferation of full stack developers. Bootcamps and curriculums all over preach the necessity of full stack skillsets like MERN (MongoDB, Express, React, and Node).

There’s certainly value to such an approach — but there is another way.

Enter JAMstack. Its mission: empower the front-end engineer.

Better performance. Higher security. Easy scaling. All with just JavaScript, API’s, and Markup.

The need to learn a full stack of technologies like MERN to be able to produce valuable, technical apps is no longer the only way. The vast majority of business use cases don’t need you re-inventing the wheel on the back-end. Authentication is a solved problem. Accepting payments is a solved problem. And so on: you can focus on becoming a CSS and JavaScript wizard to build your app and slap together tried, true, and secure API’s to fill in the gaps.

Every new API brings about a world of new use case possibilities — each more and more dynamic than the last.

And indeed, team Where In The World set out to showcase exactly those possibilities.

Showing off JAMstack, and showing off the world

Yes, that’s our cheesy slogan for what WITWorld brings to the table.

As Jeff, Tyler, Gabe, and I met over breakfast (thank you, GitHub, for the bottomless supply of delicious goods), we spit-balled ideas for what we could work on.

Here’s one. It’s one of those ideas that’s going to be either really good, or really, really bad. Do you guys know HQ Trivia? …

Right after the post-breakfast keynote ended, Jeff whispered to us:

Hey let’s call it “Where In The World”

And we were off to the races.

At a hackathon, you’re building to demo

One of the best decisions we made early on was to pick our North Star, cut the fat, and focus singularly on one goal. That goal — as it should be in most every hackathon — was: let’s build the steps we need for the demo. Nothing more, nothing less.

That means this will not be a production-ready application. It means our API keys are hard-coded into our client side code. It means our app blows up if any one of the players decides to hit the “Back” button on their browser. The CSS spacing is off. Our color pallet was a week late for Halloween. Spaghetti, but it works? Shipped it.

Our repository is publicly available, but please, please don’t look at our code. It’s a mess and a half. The fact that our last commit came in at 5:56 PM when the code complete deadline was 6:00 PM says enough.

_Netlify’s painless webhook-based CI setup had this 5:56 PM commit live on [https://witworld.live/](https://witworld.live/" rel="noopener" target="blank" title=") a minute later

With JAMstack, we sit on the shoulders of giants

Early on, we had a rough idea for how WITWorld would technically come into being. It was clear that GraphQL subscriptions would have to be at the core of it: sockets were the best way to make a “live” web app, and GraphQL has neatly packaged the concept into a “subscription”.

Just one problem: none of us had ever written a GraphQL subscription before.

Hasura to the rescue.

Hasura provides “a GraphQL server and event triggers over a Postgres database in minutes” and was one of the hackathon’s sponsors.

Converting our app from the typical read-write push-pull model into realtime over web sockets was a simple matter, in the words of Hasura’s documentation:

You can turn any query into a subscription by simply replacing query with subscription as the operation type.

And a few lines of Apollo config to pop in Hasura’s convenient web socket endpoint.

That’s just one example. We experienced this simple “2 lines of code and XYZ major feature is ready to go” paradigm over and over again:

• Facebook’s [create-react-app](https://github.com/facebook/create-react-app) gave us a full, production-ready webapp scaffold with a few command line calls
• Deploying that app to a worldwide CDN on Netlify was a matter of clicking around a pretty UI
• The combination of Apollo and the GraphQL specs meant that a clear standard existed for every kind of data operation from the client side
• [styled-components](https://www.styled-components.com/) kept the (admittedly lacking amount of) CSS in our app easy-to-use and modular
• Google Maps API meant we had an interactive world map integrated into our app after an hour of reading its docs
• Netlify’s Functions — an abstraction over AWS Lambda — gave us a perfect place to centralize our “game master” operations, critical for a smooth demo

Not to mention all the little FOSS npm libraries we used so that we didn’t spend too much time figuring out what latitude and longitude actually mean, among other pieces of glue.

Let’s not forget how much work has gone into modern browsers like Chrome and Firefox, or the people responsible for the Netlify-Slack webhooks that alerted us every time our build failed, or the industry-shifting presence of React itself. Even tools like Heroku that we touched for a single click to deploy a Hasura instance — it’s a testament to how impressive they are that they operate so smoothly with us hardly realizing their major role.

The best part: none of the above costs a single dollar to use. Not on the scale of a hackathon anyway.

Above all, we were lucky

​ (Left to right) Tadas, Gabe, Jeff, and Tyler. GitHub’s Octocat was evidently watching over us.

For the rest of the weekend, had any one of these scenarios not fallen our way, we probably wouldn’t be talking much about WITWorld today:

• 2 minutes before we went up to present the final demo, Tyler discovered a bug in our presentation setup that would have kept running the same picture for every game.
  A minute later, he had diagnosed and repaired it.
• Our app was (is) full of security holes and bugs.
  Someone could have wiped our database in two second during any of the demos.
• We happened to pick a team name that starts with “W”. This meant we had the good fortune to do the judging interview last, and the final presentation last.
  With the whole process being a time crunch, every minute of extra preparation was valuable.
• Remember your randomly-selected college roommate? Probably a 50/50 chance it was a terrible experience.
  And then there’s us: 4 strangers who miraculously survived the weekend without a single disagreement.
• Our broad range of skills and abilities meant we never got stuck on any particular development problem for more than a short period of time before someone stepped in and quickly repaired issues they had at some point run into in their own line of work.
  Hackathon projects are well known for blowing up because of some pesky bug that nobody can figure out for hours — we somehow dodged all of that.
• We’d never tested our app with more than a handful of people before we got up on stage to handle 70+.
  Our belief that Heroku could handle that many websocket connections on its free tier was blind faith.

I could go on. The weekend was a roller coaster, and yet time and time again, things just fell into place.

WITWorld will hang around as an open source project

As we don’t have concrete plans for the future of WITWorld, the immediate future will see us cleaning up the codebase, setting up an MIT license and some structured Issues, and pushing it to the point of being a reasonable public showcase of JAMstack technology.

Contributors of all skill levels are more than welcome! We’d love to keep you in the loop whether you want to contribute or just follow any progress. Join the mailing list.

JAMstack is being ushered in by one hell of a community

In the early 2000’s, you needed to buy your own server rack space to put up a website. AWS and other cloud providers had turned that concept on its head by 2010.

Today, we’re in the next stage of that evolution: you don’t need a back-end or DevOps expert to spin up your next app idea. Netlify and the rest of the API economy are on track to have turned that leaf by 2020.

Huge thank-you’s go out to those involved with the hackathon:

• Benjamin Dunphy of Real World React — hackathon organizer extraordinaire
• Quincy Larson of freeCodeCamp — life of the party and humble freeCodeCamp empire-builder
• Matt Biilman and Phil Hawksworth of Netlify — bonus points for also running JAMstack_conf
• Brian Douglas of GitHub — gracious host and provider of food
• All the API sponsors: Hasura, Fauna, Formspree, Clarifai, and Pilon

With many, many more people behind the scenes.

Events like this hackathon and the corresponding JAMstack_conf are just the beginning. We look forward to the bright future of the JAMstack community!

Big thank-you to Jeff Appareti, Gabe Greenfield, and Tyler Vick for reviewing drafts of this post. And being an awesome team to spend the weekend with.

This post was originally published on tadasant.com

Last weekend, we hosted Hack36, our first-ever hackathon at Motilal Nehru National Institute of Technology in Allahabad. It was easily one of the largest student-lead hackathons in India.

Over 600 developers from 21 different cities across India signed up for the event, vying for 100,000 Indian Rupees in prizes.

After a thorough analysis of their resumes, as well as open source profiles, we chose 180 hackers to compete.

We also had guest speakers, including the creator of freeCodeCamp.org himself, Quincy Larson.

Quincy Larson during one of the talks

As the tech coordinator of the event, I got to interact with all 52 teams personally. Not all the teams were able to implement their idea, but all of them did a commendable job during those 36 hours.

Since I had a firsthand insight of all the products developed, I decided to share the winners and my own top picks from Hack36.

DEXTER — First Place

Team: Abhishek Sharma, Himanshu Shekhar, Souvik Sen, Madhurjya Pegu
Code: https://github.com/himanshub16/dexter

Ever wondered if you could talk to your computer in your natural language, and it writes the code for you, and that too in your favorite language? Well, Dexter is an AI-based code editor that allows you to code simultaneously in JavaScript and Python just by conversing with it.

It supports two of the most widely used languages in the country, Hindi and English. And in my opinion, it has, perhaps, the best design and interface among all the products developed.

Jarvis Bot — First Runner Up

Team: Mohit Khare, Abhey Rana, Prabhat Singh, Avishek Santhaliya
Code: https://github.com/mkfeuhrer/JarvisBot

It’s an intelligent bot that lets you perform utility and fun stuff like games. Built with Python and ZulipChat-API, Jarvis-Bot is the most feature-rich unofficial ZulipChat Bot. It has a bunch of features including dictionary based search and to-do list.

You can even use this bot to log in to a remote system through SSH. The bot also features four interesting games such as Hangman, Scrabble etc, all available at the click of a button. Isn’t it cool ..?

MedX — Second Runner Up

Team: Rashmitha Yellapragada, Gunjan Singh, Naguboyina Sravya, Vrinda Agarwal
Code: https://github.com/sravya31/hacker-champs

MedX is a platform for easy storage and access of electronic medical records(EMR) that would revolutionize the current health care services. It uses the Ethereum block chain to record patient’s medical information. It grants the user complete control over his/her own medical records and allows to make certain aspects public or private, while still being stored in a decentralized way.

The documents are being stored on IPFS. Moreover, the app also implements certain access control levels to make sure one gets access only to the required data and not the complete medical history of a patient.

TabORanger — Chrome Extension

Team: Abhinav Dixit, Vaibhav Bhardwaj, ARPIT GUPTA, SUSHANT OBEROI
Code: https://github.com/soc3/TabORanger

Developers, in general, have lots of tabs opened in the browser. After a certain number of tabs, it gets really difficult to manage those. TabORanger, a chrome extension, groups tabs on the basis of the web page content using Machine Learning.

The extension also has an option to categorize the tabs on the basis of titles instead of the whole page content to make the whole process much faster.

SocioIntegrate App

Team: Yerra Bala Praneeth Kumar, PRANAYKUMAR ANUGURTI, Poorna Chandu Gade, Kandula Sumanth
Code: https://github.com/PraneethYerra/hack36-android

This is actually one of my favorites solely due to its unique idea and implementation.The SocioIntegrate App attempts to mitigate the gap between the Facebook Friends engaging them in an Anonymous Chat Game.

The game involves both users connecting randomly based on their interests (data retrieved from Facebook Graph API). Then they play a game (chat till a threshold limit of messages) to reveal the name of their friend. The one who succeeds first gains Flame Points. A user can then use his gained flame points to Prank a Friend on the app itself where the other user doesn’t know the details about him. The Points can also be redeemed at certain outlets.

EyeVis

Team: Akshit Sharma, Divyanshu Kapoor, SATYAM KUMAR GUPTA, Aman Shroff
Code: https://github.com/khitk9738/EyeVis

It’s a Project(Python/Android) based on Object detection using Google’s Tensor-flow to provide vision to the blind, further implementing Optical Character Recognition, Read It Aloud, Google translations for different languages & Scene Recognition saving day-to-day problems of millions.

The idea is not much unique but the way the app is hacked using a bunch of APIs and third-party services really makes it stand out from the crowd. The app if implemented properly and trained on a good data set can really make a difference for a certain part of the community.

Alexa Care Buddy

Team: Ashish Jha, Rohan Maity, Saumya Wardhan, Siddharth Kathuria
Code: https://github.com/TheDreamSaver/hack36-alexa-healthcare

As the name suggests, it’s an Alexa app that aims to find nearby medical stores on the basis of medicine searched. It also suggests a substitute for the medicine in case the searched medicine is not available.

The app also has an inbuilt navigation to guide a user to the shop. Moreover, the app can also guide you through simple first-aid procedures like the sprain, paper cut etc. It can also teach you common procedures like CPR in cases of emergencies.

FInal Words

Even though it was only the first of its kind event in the College, the event was a great success. It marked the first of many such developers events yet to be organized. I hope the legacy continues !!

The above list was compiled by me and some interesting ideas might have left out. Please suggest those ideas in the comments. :D

Daniel Borowski published a great list of coding challenges you can join for fun and/or to test your programming skills. Contests like TopCoder or Google Code Jam are well-designed and offer high rewards. The competition is usually very high as well. In this article, I’d like to list less-known online contest you can join in 2018. (Note: the vast majority of them isn’t based on algorithmic problems).

Js13kgames

Link: http://js13kgames.com

Challenge:

It’s a JavaScript coding competition for HTML5 Game Developers. The game assets should be smaller than or equal to 13 kilobytes. It must work and be playable in at least two browsers: Firefox and Chrome. The rules also define the main theme, and it’s highly advised to follow it in your game (2017 theme- “lost”).

Prizes:

Sponsor’s packages such as:

• Three copies of Evil Glitch game by Agar3s available on Steam.
• Three lifetime and ten year-long licenses for Phaser Editor from Arian Fornaris.
• Thirty paid GitHub plans — personal accounts with unlimited private repositories for twelve months.
• Ten 6-month PlayCanvas Personal accounts offering a cloud-hosted, collaborative platform for building games.
• Two Personal licenses for one year each of Construct 3 game engine created by Scirra.
• Two copies of Asset Forge Deluxe tool from Kenney.nl.

Past winners:

• Ryan ‘Rybar’ Malm — you’re a lowly space mining bot who suffers a terrible accident and is separated from your crew. Find enough fuel and body components to repair yourself and explore.
• Maxime Euziere — a big puzzle game and a long journey to find a lost kid.
• Rémi Vansteelandt — get control of the sectors back by capturing beacons and defending them against enemy units.

Yelp Dataset challenge

Link: https://www.yelp.com/dataset/challenge

Challenge:

The challenge calls students to use Yelp dataset in innovative ways. It’s a chance to conduct research or analysis on Yelp data and share your discoveries. For example, the 2017 set included information about local businesses in 12 metropolitan areas from 4 countries.

Prizes:

• ten awards for $5,000

Past winners:

• “Semantic Scan: Detecting Subtle, Spatially Localized Events in Text Streams”. Abhinav Maurya, Kenton Murray, Yandong Liu, Chris Dyer, William W. Cohen, and Daniel B. Neill.
• “Topic Regularized Matrix Factorization for Review Based Rating Prediction”. Jiachen Li, Yan Wang, Xiangyu Sun, Chengliang Lian, and Ming Yao, from the Language Technologies Institute, School of Computer Science, at Carnegie Mellon University.
• “From Group to Individual Labels Using Deep Features”. Dimitrios Kotzias (University of California, Irvine), Misha Denil (University of Oxford, UK), Nando De Freitas (University of Oxford, UK, and Canadian Institute for Advanced Research), and Padhraic Smyth (University of California, Irvine).

XD HAX Developer Challenge

Link: https://xdhax.devpost.com/

Challenge:

Developers are asked to build innovative apps utilizing cloud technologies. Such apps are to benefit small businesses worldwide. Competition is divided into categories:

• Best NEW App integration (with Xero API)
• Best enhancement of an existing App integration
• Most Innovative use of Xero’s APIs
• Best New Open Source Project with Xero’s API

Prizes:

$5000 in Amazon Web Services credits, $2500 in cash, plus featuring in Xero’s resources. Additionally, in the best integration category, the winner gets an opportunity to exhibit in Startup Alley at a Xerocon of your choice. This has an approximate $5000 value.

Past winners:

• The revolutionary new card that makes business spending as beautiful as Xero makes accounting.
• Account Management Dashboard (AMD).
• TAX which helps startups to deal with taxes.

OPEN OIT CHALLENGE 4.0

Link: https://iot.eclipse.org/open-iot-challenge/

Challenge:

You need to create a solution based on open standards and open source technology. The solutions are judged on the following criteria:

• Applicability of a solution to a specific industry, like Smart Cities, Industrie 4.0, and Remote Health.
• Completeness of solution.
• Use of open standards and open source technology.
• Amount of community discussion from the participants when they built their solution.

Prizes:

1st prize:

• $3,000 gift card to be used in an online shop for electronic supplies and open hardware.
• $1,000 scholarship to attend a future Eclipse Event in 2017.
• 1 Reactive Blocks professional license (EUR 4,800).

2nd prize:

• $1,000 gift card to be used in an online shop for electronic supplies and open hardware.
• 1 Reactive Blocks professional license (EUR 4,800).

3rd prize:

• $500 gift card to be used in an online shop for electronic supplies and open hardware.
• 1 Reactive Blocks professional license (EUR 4,800).

Past winners:

• Sebastien Lambour & team — InMoodForLife: Sleep analysis for mood disorders.
• Siva Prasad Katru & team — The solution to help farmers execute agricultural operations in smarter and efficient way.
• Tom Morocz & team — RHDS which performs a near real-time home Home Energy Audit on a minute by minute basis.

_Photo by [Unsplash](https://unsplash.com/photos/MuIvHRJbjA8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">James Owen on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Space App challenge

Link: https://2017.spaceappschallenge.org/

Start date: April 2018

Challenge:

Space App challenge is a NASA International hackathon that occurs over 48 hours in cities around the world. It’s about building apps judged in many different categories:

• Ideate and Create! Challenges in this category will ask you to interpret NASA Earth Science data creatively. You will be asked to design new means to experience NASA Earth Science data and technologies.
• Our ecological neighborhood. Challenges in this category will ask you to use NASA Earth Science data to study ecological systems. You will also generate solutions to understand life here on Earth better.
• Warning! Danger ahead. This category will ask you to analyze NASA data. You will assist in monitoring natural disasters and phenomena associated with health risks. You will also be asked to assess their impacts on life and property.
• Planetary blues. In this category will ask you to analyze and visualize NASA’s data on the hydrosphere and the cryosphere.
• The Earth and us. This category will ask you to combine NASA Earth Science data with sociological and economic information. The result will generate new understanding and perspectives on human-environment interactions.

_Photo by [Unsplash](https://unsplash.com/photos/z8lfwpQVXJo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Team UI8 on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Prizes:

• In 2015, Global had a chance to attend the viewing opportunity for the Cygnus CRS OA-4 launch. Cygnus CRS OA-4 took cargo and experiments to the International Space Station.
• In 2016, Global winners could attend the launch of OSIRIS-Rex, visiting the asteroid Bennu.

Past winners:

• Best use of data: Scintilla mitigates the impact of poor air quality on the global community. This is done by democratizing air quality data collection.
• Best use of hardware: The Canaria system of CO2 monitor patch and earpiece acts as a lifeline to the wearer. It simultaneously monitors heart rate, blood oxygen, and atmospheric CO2 levels.
• Galactic impact: This is a web tool that provides the near real-time visualization of glacier surface velocity fields. It is obtained by processing free SENTINEL-1 Synthetic Aperture Radar images through our own algorithm. This is enhanced with the addition of environmental variables from NASA GIBS.
• Best mission concept: The solution is a data glove to be worn by astronauts as part of their space suit. The data glove is a network of wireless devices that provide communications in a variety of environments. These include subterranean environments, like caves, caverns, and lava tubes on the moon, Mars, and asteroids.
• People’s choice: MarsHopper is a plane for the investigation of Mars poles and its surroundings. It uses CO2, that in solid form covers surface to create jet thrust.
• Most inspirational: Kid On The Moon is an interactive app. It fosters curiosity to inspire the next generation of space explorers.

TADHack

Link: https://tadhack.com/2017/

Challenge:

TEDHack is the largest telecoms-focused hackathon worldwide. The competition is divided into following categories:

• Hackhathon. This category is an idea or an answer to a sponsor’s challenge. You can work on your ideas before the event, or create ideas during the event from all the great networking opportunities.
• Showcase. This category is for products that have already been released commercially. It can also include products that have had significant development.

Prizes:

$1000 — $200 in cash (dependently on category), plus packages from sponsors.

Past winners:

• Hack: snappy kamailio. By Daniel-Constantin Mierla.
• Hack: Outsider. By Ermir Suldashi.
• Hack: Avengerrs. By Mchotsa Banda, Daryl Lukas, Chobela Kakumbi, Itati Dzekedzeke, Joshua Chipile & Sibusiso Ngoma.

(More categories and winners.)

React Riot

Link: https://www.reactriot.com/

Challenge:

48h to build an app by using React JS. There is no specific topic or theme. Entries are judged on a 1–5 scale across 3 dimensions:

• Innovation — How original is the idea and execution?
• Design — How good does it look and feel to use?
• Utility / Fun — Is the site offering a service I’d use again and again?

Prizes:

Sponsors provide prizes, no cash rewards. Examples with estimated values:

• Algolia — $500 gift card of your choice
• Sencha — ExtReact Premium License year per team member ($4,780 value)
• Algolia — 2 year Startup Plan per team member ($4,704 value)
• Frontend Masters — 6 months membership to Frontend Masters per team member ($936 value)
• ag-Grid — 1 Developer license ($495 value)
• Github — 1-year Developer Plan per team member ($336 value)
• AgileBits — 1 Password license per team member ($144 value)

Past winners:

• The Definitely Ending Story — Get your thinking cap on to puzzle your way into Granny’s house. Navigate your way around town, and talk to the townsfolk to pick up items.
• Composer — Lets you choose chords and instrument types to create your very own sound composition, that you can share with your friends.
• Okay, Fine! — A chat room that uses AI to analyze and visualize tone
• DungeonLogic — You are helping to the dark mage, that has a strange hobby. He collects the coins in strange places and uses dark magic to control the environment, for example, to lift something or pull down.
• PewPew — Pew pew is a real-time multiplayer game where players can battle each other using their voice.
• Fill Me Up — FillMeUp addresses a major pain in Nepal — refueling vehicles. It is a platform for suppliers to reach out to more consumers by providing valuable petrol pump statistics and information.

Stellar Build Challenge

Link: https://www.stellar.org/lumens/build/

Challenge:

Contestants are asked to build applications which match following requirements:

• Continues usability improvements and polish to what is there now.
• Applications using multi-sig in a novel and interesting ways.
• Open federation service or other applications taking advantage of a federation.
• Sending lumens to any address.

You can also build a wallet solution which matches following dimensions:

• Continue usability improvements and polish to what is there now.
• Has multiple accounts.
• Presents good design.
• Sends lumens to any email address.
• Has other features that allow easy on-boarding and increased virality.

Other categories include tokens, issuing ICO, trading tools or remittance app.

Prizes:

2 000 000–350 000 Lumens (Lumens are the native asset of the Stellar network)

Past winners:

• Popcoin — metered billing for busy developers.
• Tonaira — allows you to send money to your family and friends for as low as 1%.
• BlackWallet — it supports lumens, assets, and tokens, and makes it easy for you to send nor receive them.
• eSACCO — similar financial needs with varied financial journeys means we each require personalized solutions. That’s exactly what eSSACO delivers.
• StellarTerm — an open source client for the Stellar network. Send, receive, and trade assets on the Stellar network easily with StellarTerm.

ANGULAR ATTACK

Link: https://www.angularattack.com/

Challenge:

All entries have to be applications created with Angular. You have 48 hours to build your solution and pass it through (entries should be web applications). Apps will be judged on a 1–5 scale across 3 dimensions:

• Innovation — How original is the idea and execution?
• Design — How good does it look and feel to use?
• Utility / Fun — Is the site offering a service I’d use again and again?

Prizes:

Packages from sponsors, for example:

• Kendo UI — $500 gift card of your choice
• NativeScript — $500 gift card of your choice
• Kendo UI — BONUS $2,000 gift card of your choice if you use Kendo UI
• NativeScript — BONUS $2,000 gift card of your choice if you use NativeScript
• Frontend Masters — 6 months membership to Frontend Masters per team member ($936 value)
• Scotch — 1-year membership to Scotch School per team member ($480 value)
• SitePoint — 1-year Premium membership per team member ($396 value)
• Github — 1-year Developer Plan per team member ($336 value)
• Rollbar — 6 months Bootstrap Plan ($300 value)
• AgileBits — 1 password license per team member ($144 value)

Past winners:

• Team winner — the game provides a 6x6 board with items and a set of clues.
• Solo winner — a drum machine and chat application. This application lets you create and listen to beats in real time with your peers. This can be accomplished irrespective of the places where your peer composer resides.
• Innovation winner — a fun immersive augmented reality game. In this game, toddlers have to spot the alphabets using the device camera.
• Design winner — a turn-based multiplayer game that players need throws a rock at the opponent with their slings.
• Utility/fun winner — it is a one-page web application that gives the download links to the videos.
• Public favorite — one of the most awesome tools to create your own story.

Node Knockout

Link: https://www.nodeknockout.com/

Challenge:

Node Knockout is an online hackathon. Teams compete over a 48 hour period to build the best app they can, using Node.js. After app submission, it is scored by one of the expert judges:

• Innovation — How original is the idea and execution?
• Design — How good does it look and feel to use?
• Utility / Fun — Is the site offering a service I’d use again and again?

Prizes:

Founded by sponsors, no cash rewards. For example, “Judges favorite” received:

• Heroku — $500 gift card of your choice
• Frontend Masters — 1year subscription per team member (up to $1,872 value)
• Blitline — $100 credit per team member (up to $400 value)
• Github — 1-year subscription per team member (up to $336 value)
• AgileBits 1Password — 1-year subscription per team member (up to $144 value)
• Papertrail — 1-year subscription (up to $84 value)
• Component IO — 6 months Standard plan ($60 value)
• Rollbar — 1-month Bootstrap plan ($49 value)

Past winners:

• The best overall score by judges was awarded to the ? Store, This is a magical place where you can design and actually order custom emoji hats, t-shirts, and mugs and get them delivered the mail just a week or two later.
• The best overall score by participants was awarded to DuckNockout. DuckNockout is a technological shooting game that brings nostalgia from Duck Hunt of the 80's.
• The highest innovation score — tech word assembling game with git commands.
• The highest design score — a fun little game made in an 8-bit-like style. You’ve found the perfect wave, with all that’s left to do is to ride it without falling.
• The highest utility/fun score — this is a game that uses your microphone as input. If you’re loud enough, the character will move right. If you’re quiet, the character will move left. Aim for the branches. If you hit the bottom, you lose.
• The most votes — multiplayer game includes knowledge, quickness, forecast.

24 Pull Requests

Link: https://24pullrequests.com/about

Start date: December 1–24

Challenge:

You’re asked to send 24 pull requests between December 1st and December 24th. The idea is basically to encourage developers to give back to open source with little gifts of code throughout December.

Prizes:

Becoming true OS developer

_Photo by [Unsplash](https://unsplash.com/photos/4p0C_OiXNiM?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Mariah Ashby on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

ATOS IT challenge

Link: https://www.atositchallenge.net/

Challenge:

Come up with an innovative concept for an application based on Chatbots & AI. The topic for the Atos IT Challenge 2018 is as follows:

“Devise an innovative use case and build a prototype leveraging Artificial Intelligence and conversational interfaces. Show how this can provide benefit to the people and/or transform business, and how you could further develop your solution and take it to market.”

You can use devices like the Amazon Echo Dot or Google’s AIY Projects with a Raspberry Pi to provide an interface, a web service or APIs such as API.ai or wit.ai.

Prizes:

• 1st prize: €10,000.
• The two finalists (2nd, 3rd prize) get respectively €5,000 and €3,000.

Past winners:

• Quo (Lancaster University in the UK)
• Evoto (Loughborough University in the UK)
• E-tickets (ENSEIRB-MATMECA in France)

_[The 3 finalists of 2017 ATOS IT challenge](https://www.atositchallenge.net/edition-2017/" rel="noopener" target="blank" title=")

Mercedes Benz Digital Challenge

Link: http://www.mercedes-benz-challenge.com/

Challenge:

Develop new and innovative use cases (app or another idea) using Mercedes car emulator, mock APIs, and SDKs. In the Digital Challenge, you get access to 80+ mock APIs, mobile SDKs (iOS and Android), and a car emulator.

The APIs relate to car chassis, digital keys, points of interest, parking, and so much more. And, if combined with external APIs, the only limit should be contestant’s creativity.

Prizes:

• 1st place: Besides €15K, the winning team will be awarded two tickets to the 2017 Lisbon Web Summit. There they will present their solution alongside Mercedes-Benz.
• 2nd place: The runners-up will receive €6K and the chance to continue discussions with the Mercedes-Benz team. The runners-up will potentially continue development beyond the Digital Challenge.
• 3rd place: The second runners-up will receive €3K and the chance to continue discussions with the Mercedes-Benz team. The second runners-up will potentially continue development beyond the Digital Challenge.

Past winners:

1. First prize Safe drive. Safe_drive is an app that monitors driving aptitude. It can also restore driver’s attention, testing driver’s ability to answer, take safety measures, and alert emergency services.
2. Second prize KarMa KarMa is an Android application designed using Mercedes Benz APIs. It provides a centralized platform, on which, the users can rely upon for all their car needs.
3. Third prize Virtuo — Virtuo is a game changer in the car rental industry.

$100,000 Small Business App Showdown 2018

Link: https://intuit.promo.eprizes.com/showdown2018/

Challenge:

The challenge is to publish a small business app on Apps.com. To be eligible, apps must be published on the QuickBooks App Store at Apps.com between August 16, 2017, and August 15, 2018.

Prizes:

Each of ten finalists gets:

• featured space in a Finalists gallery at QuickBooks Connect exhibition hall,
• a QuickBooks Connect pass,
• opportunity to demonstrate and pitch an app to a panel of judges and compete for $100,000 Grand prize,
• one additional QuickBooks Connect pass for a business partner,
• and three nights’ accommodations at a hotel determined by Sponsor in its sole discretion.

One grand prize is a $100,000 check.

Past winners:

ShopVOX . ShopVOX is a comprehensive web-based, easy to use solution for custom manufacturer businesses. It enables such businesses to manage everything in their shop. This includes sales leads, quotes, inventory, and workflow. It can also include production, invoices, staff, customers, vendors and much more.

Coding contest

Link: https://www.codingcontest.org/en/contest/ccc/

Start date: 27 April 2018

Challenge:

Programmatic tests and puzzles to solve during international competition in many locations. These will also be available online (all of them start at the same time).

Prizes:

• Prize for the online winner is 50€ Amazon voucher.
• Prizes for winners in locations are hosted by particular sponsors — “In locations with a raffle, you have the chance to win various prizes. The better you score in the contest, the more lots you get for the raffle. During the award ceremony, we draw lots and the lucky winners can pick one of the remaining prizes.”

Past winners:

Winners are divided accordingly to their locations and challenge categories.

Community Kickstarter Contest 2018

Link: https://www.milestonesys.com/nl/campaigns/milestone-community-kickstarter-contest-2018/

Challenge:

“Contest that invites coders and developers to come up with integration ideas that push the boundaries of video management.”

Developers have to create the idea built on top of Milestone’s video management software. They must also utilize the Milestone Integration Platform and the Software Development Kit (MIP SDK). The winning solution would be a concept, new functionality to the platform, a widget or code. The winning solution must be commercially viable and technologically possible. Additionally, it must function given the current features of the Milestone platform.

Prizes:

• $10,000 Cash prizes
• $20,000 development & certification resources
• $35,000 Marketing & event activities
• 5 Honorable mentions

Past winners:

Parking Spotter — an application that helps end-users find the closest available parking spot.

Aerolab’s Coding Challenge 2017

Link: https://aerolab.co/coding-challenge?medium

Challenge:

You’re asked to build a product grid for a reward program:

• Aerolab gives you the base UI and the API, and you’re welcome to use it as it is or improve it if you consider it necessary. The final product should be effective and yet visually attractive.
• The main goal of your idea should be helping users redeem items through a points-based system.
• You are allowed to use any technology you want. Finalists will be ranked according to a set of criteria, with extra points awarded for Innovation, Efficiency, and Visuals.

Prizes:

• The 3rd prize is a gift card for Bookdepository
• The 2nd prize is a pair of JBL headphones
• The 1st prize is a Raspberry Pi 3, and a year-long Premium Subscription to Zeit.co

If you like these contests, you might also be interested in Voucherify Developer Challenge. Learn various APIs and win a hackable Chromebook!

When an experiment with existing open source technology does a “good enough” job

The Victoria Police are the primary law enforcement agency of Victoria, Australia. With over 16,000 vehicles stolen in Victoria this past year — at a cost of about $170 million — the police department is experimenting with a variety of technology-driven solutions to crackdown on car theft. They call this system BlueNet.

To help prevent fraudulent sales of stolen vehicles, there is already a VicRoads web-based service for checking the status of vehicle registrations. The department has also invested in a stationary license plate scanner — a fixed tripod camera which scans passing traffic to automatically identify stolen vehicles.

Don’t ask me why, but one afternoon I had the desire to prototype a vehicle-mounted license plate scanner that would automatically notify you if a vehicle had been stolen or was unregistered. Understanding that these individual components existed, I wondered how difficult it would be to wire them together.

But it was after a bit of googling that I discovered the Victoria Police had recently undergone a trial of a similar device, and the estimated cost of roll out was somewhere in the vicinity of $86,000,000. One astute commenter pointed out that the $86M cost to fit out 220 vehicles comes in at a rather thirsty $390,909 per vehicle.

Surely we can do a bit better than that.

Existing stationary license plate recognition systems

The Success Criteria

Before getting started, I outlined a few key requirements for product design.

Requirement #1: The image processing must be performed locally

Streaming live video to a central processing warehouse seemed the least efficient approach to solving this problem. Besides the whopping bill for data traffic, you’re also introducing network latency into a process which may already be quite slow.

Although a centralized machine learning algorithm is only going to get more accurate over time, I wanted to learn if an local on-device implementation would be “good enough”.

Requirement #2: It must work with low quality images

Since I don’t have a Raspberry Pi camera or USB webcam, so I’ll be using dashcam footage — it’s readily available and an ideal source of sample data. As an added bonus, dashcam video represents the overall quality of footage you’d expect from vehicle mounted cameras.

Requirement #3: It needs to be built using open source technology

Relying upon a proprietary software means you’ll get stung every time you request a change or enhancement — and the stinging will continue for every request made thereafter. Using open source technology is a no-brainer.

My solution

At a high level, my solution takes an image from a dashcam video, pumps it through an open source license plate recognition system installed locally on the device, queries the registration check service, and then returns the results for display.

The data returned to the device installed in the law enforcement vehicle includes the vehicle’s make and model (which it only uses to verify whether the plates have been stolen), the registration status, and any notifications of the vehicle being reported stolen.

If that sounds rather simple, it’s because it really is. For example, the image processing can all be handled by the openalpr library.

This is really all that’s involved to recognize the characters on a license plate:

A Minor Caveat
Public access to the VicRoads APIs is not available, so license plate checks occur via web scraping for this prototype. While generally frowned upon — this is a proof of concept and I’m not slamming anyone’s servers.

Here’s what the dirtiness of my proof-of-concept scraping looks like:

Results

I must say I was pleasantly surprised.

I expected the open source license plate recognition to be pretty rubbish. Additionally, the image recognition algorithms are probably not optimised for Australian license plates.

The solution was able to recognise license plates in a wide field of view.

Annotations added for effect. Number plate identified despite reflections and lens distortion.

Although, the solution would occasionally have issues with particular letters.

Incorrect reading of plate, mistook the M for an H

But … the solution would eventually get them correct.

A few frames later, the M is correctly identified and at a higher confidence rating

As you can see in the above two images, processing the image a couple of frames later jumped from a confidence rating of 87% to a hair over 91%.

I’m confident, pardon the pun, that the accuracy could be improved by increasing the sample rate, and then sorting by the highest confidence rating. Alternatively a threshold could be set that only accepts a confidence of greater than 90% before going on to validate the registration number.

Those are very straight forward code-first fixes, and don’t preclude the training of the license plate recognition software with a local data set.

The $86,000,000 Question

To be fair, I have absolutely no clue what the $86M figure includes — nor can I speak to the accuracy of my open source tool with no localized training vs. the pilot BlueNet system.

I would expect part of that budget includes the replacement of several legacy databases and software applications to support the high frequency, low latency querying of license plates several times per second, per vehicle.

On the other hand, the cost of ~$391k per vehicle seems pretty rich — especially if the BlueNet isn’t particularly accurate and there are no large scale IT projects to decommission or upgrade dependent systems.

Future Applications

While it’s easy to get caught up in the Orwellian nature of an “always on” network of license plate snitchers, there are many positive applications of this technology. Imagine a passive system scanning fellow motorists for an abductors car that automatically alerts authorities and family members to their current location and direction.

Teslas vehicles are already brimming with cameras and sensors with the ability to receive OTA updates — imagine turning these into a fleet of virtual good samaritans. Ubers and Lyft drivers could also be outfitted with these devices to dramatically increase the coverage area.

Using open source technology and existing components, it seems possible to offer a solution that provides a much higher rate of return — for an investment much less than $86M.

Part 2 — I’ve published an update, in which I test with my own footage and catch an unregistered vehicle, over here:

Remember that $86 million license plate scanner I replicated? Here’s what happened next.
_Successes, failures, and catching one very naughty driver_medium.freecodecamp.org

I just returned home from my 6th hackathon in less than a year. It was a long, tiring, and amazing 24 hours — and totally worth it!

Every time I attend one of these events, it feels like I am getting a month’s worth of learning, all crammed into a single weekend.

On top of that I’ve met the most amazing people, built some cool projects (most of my portfolio outside of work), and incorporated a company. Which has been so worth it for a few hours of lost sleep here and there. ?

I am definitely planning to attend more in the future, and, if you haven’t been to one yet, I hope you might consider it for the future.

Types of hackathons

There are many different types of hackathons, but they all have several things in common:

• Time limit — usually between 8 and 48 hours
• Theme — organizers will ask that you build a certain type of application (like Internet-of-Things) or they’ll tell you to use a certain technology
• Prizes — generally awarded for the best overall applications and for apps that fit into certain categories, or use a certain technology

There is usually plenty of information online about the rules, judging, technologies, etc. It doesn’t take that long to read about the event and avoid surprises when you get there. Quite a few hackathons are for only for college students, and in those cases adults can sometimes attend as mentors, but not participants.

Several hackathons I’ve been to even had a Q&A or panel discussion first to talk about what they were looking for in app submissions. Some also have online boards to team up and get to know each other prior to the event. Meeting staff and participants early on helps to ease my social anxiety and give me a confidence boost.

FYI: Some of my favorite hackathons are Give Camp, Start-up Weekend, and Civic-minded local hacks. Let me know if there is another one I should attend!

Why should you go?

I already mentioned some reasons but here is a an overview:

1. Networking — This is a given. I’ve met politicians, business people, companies, developers, designers, and plenty of rockstars (figuratively, of course ?) at these events. I’m shy, but I force myself to get out and meet at least a few people each time. I’ve never met someone I regret meeting at a hack!
2. Portfolio — I have several solid, well-designed portfolio pieces that came out of hackathons. Some companies have talked to me because they liked what I built at one. Make sure you get on a team where you think you will fit in well and try to work on an idea you are passionate about or at least very interested in. Having a designer on the team is super helpful but I always try to look at some design inspiration before I go to one of these so I can whip up a layout and design doc if necessary. I think it’s good to treat every project as a potential portfolio app.
3. Confidence — I’ve found it to be surprisingly common that new developers think their skills are sub-par and they won’t be able to make meaningful contributions to a team. Plenty of non-technical people are needed at these events and even people who want to code but only know HTML or CSS can help on a team.
4. Teamwork — The importance of learning to work with other developers when you are new cannot be overstated. It’s very, very important. You learn to partition tasks, share a codebase, and get along in a sometimes stressful environment. Sometimes apps crash and things don’t work out. Sometimes you or your teammate will get tired or frustrated or grumpy. Going through this experience together forces you to learn how to work together through the good and the bad as a team.
5. Communication Skills — As a good teammate, you should always be talking to your group. “I just pushed code, can you pull.” “I’m working on this…” “How are you doing with that?” “You seem frustrated, let’s take a walk and get some fresh air.” It forces you be open and explicit about what you are thinking and doing. More importantly, it makes you think about what’s going on around you and how your teammates are doing. Your communication skills will improve!

What to expect

Expect the unexpected. Things will go wrong with your code. Venues will be loud or really cold. You may need to pivot on your idea after you already started working on it.

The best thing you can do is to prepare as much as you can. Most hackathons (if they are 24+ hours) expect some participants to be staying overnight and they will have some couches to crash on.

In preparation for staying up very late (or overnight) it’s not a bad idea to bring extra warm clothes, a blanket and pillow (or, better, a sleeping bag), snacks, and energy beverages.

Before you leave your house, check and make sure you have extra headphones, chargers, and all the devices you are going to need as well as daily items that you use. Even if I live close, I don’t go home to sleep because I know I will sleep in and end up feeling lazy and losing time.

As for the coding part: knowing how to use generators or starter-kits can be a huge advantage going in. This can prevent a lot of headaches and wasted time and let you do more actual coding without beating your head against the wall getting things set up from scratch.

The less complicated your code is, the better: time is at a premium during these events and other people of various skill levels will likely be jumping in and coding with you.

If you want to do an ambitious mobile app, that’s great — as long as you are considering the time that it takes to set up and get all of the emulators up and running or devices working on whatever wifi they might have at that venue.

I’ve done web, mobile, and cloud projects at hackathons and web app are by far the fastest for me to set up and start building, even though I develop with cross-platform mobile and cloud solutions almost every day.

With a little planning, I am much more productive and end up having more fun (and getting more sleep!).

In short, go to a hackathon!

Let me know if you have any questions or if I missed something here. I would love to read about some of your experiences as well!

Now I’m going to catch up on some shut eye ?

I’ve always envisioned hackathons as being highly technical, events where just walking in the door implied serious knowledge of all types of programming.

Even though I’d been curious about these pressure-chamber creativity competitions, I’d always assumed that my skill-set — a jack-of-all-trades amalgamation that included almost no coding experience — wouldn’t add much value to a hackathon team.

“Hackathon shame” was just one reason why I recently decided to teach myself to code using Free Code Camp. Their front end development curriculum was extremely challenging, but the community helped me sustain the momentum I needed to finish it.

And, months later, I felt that I had finally crossed the valley of misunderstanding, which falls somewhere between basic HTML tags and advanced JavaScript algorithms.

This process gave me enough confidence to finally attempt a hackathon — and man should I have done so sooner.

I submitted a last-minute application to jump aboard the StartupBus heading from San Francisco to Boulder, Colorado. In total there are six buses, each carrying a couple dozen participants, who form teams and attempt to create a startup in 72 hours. While on a moving bus with unreliable internet and live product pitches every couple of hours.

Yeah, we haven’t been sleeping much.

As it turns out, building a technical product requires way more than just strong developers. Our 5-person team includes three people who are non-technical.

For the past 48 hours, we’ve been building and iterating on a product called Tub.

Tub integrates with “saved for later” content via tools like Pocket, Instapaper, YouTube’s watch-later feature, Chrome plugins, Twitter and more. Our research has shown that loads of people save content to enjoy later, but most of them never get around to it.

We believe that there is time to consume the content you want. The problem is that your time is fragmented.

By hooking into technologies — such as Uber’s new TripExperiences API — Tub’s chatbot delivers content based on your mood, and how much time you have available. One such fragment of time is when you’re waiting for an Uber to come pick you up.

Tub Mockup Using Uber API

We’re also building an SMS delivery feature using Cisco’s Tropo API, for users who want to text back and forth with Tub.

With Free Code Camp, I built out JavaScript applications that touched a variety of APIs, such as OpenWeatherMap, Twitch, and Wikipedia. So I already had experience building API integrations.

I was excited to learn that Uber and Cisco were sponsoring the StartupBus, and providing engineering support to teams who incorporated their APIs into their product idea.

There will hopefully be more to this story, but for now, the SF StartupBus has rolled into Boulder. We’ve pitched Tub to live audiences in both Las Vegas and Salt Lake City. And tomorrow morning we’ll pitch to TechStars, and see how we fare against our competition.

Don’t drown in an ocean of content — get in the Tub! We’re on Facebook and Twitter, and you can sign up for beta access at www.FillTheTub.com ?

New products and services need hackers, hustlers, designers, and managers to get into the world.

Go ahead and enter a hackathon in your area. There’s a good chance you’re already ready to withstand the pressure and bring a project to life. You just don’t know it yet.