The Internal Coding Tool Every Startup Needs
Nearly three and a half years ago I co-founded Mimir with Prahasith Veluvolu and Colton Voege. As a co-founder, I wear many hats. I currently manage:
- Mimir’s infrastructure (AWS)
- DevOps/CICD
- Systems administration
- All of Mimir’s computationally intensive services (plagiarism detection, code testing servers, etc.)
- Data science
- Artificial intelligence work (when I’m lucky enough!)
At Mimir, there are many internally coded tools that are actively maintained and used, but most of these are very niche (like most that are internally coded) to our startup. I’ve worked on multiple services and products that Mimir offers and have a fairly deep understanding of most of our code bases. I’ve seen my fair share of implementations, solved all sorts of issues, and personally designed plenty of my own.
In my experience I’ve found that when technical issues arise, an open source tool or free offering will often be able to solve most problems.
Reinventing the wheel takes time, and with the current state of open source, there aren’t many wheels left that need inventing.
GitHub and GitLab contain a variety of open source products that are made by communities that care about the product they collectively maintain. This challenges developers to think that rolling an independently created solution to a problem is ever a good idea (especially not crypto!).
Expanding the team at Mimir this past year has made me rethink how I work. When our team grew, I realized that my position was moving away from intense systems administration and infrastructure management (that I’d worked really hard to automate), and toward creating new features and implementing new tools to make the rest of my team more independently effective. Empowering my team to be more successful is now part of what I do.
Rolling your own solution is a last resort these days. If a usable product or repository can be found, it allows you to create a quick and efficient solution to a problem you need to solve. When open source repositories aren’t available, that’s the moment you must consider writing it yourself. With that being the case, there is one tool that every startup should consider writing internally.
I realized that I could create a tool to increase my team’s productivity while turning my professional hours spent into a multiplier for all each team member’s time. Equipping individuals to be more productive in their roles has a larger impact on Mimir’s startup success as a whole.
That’s how Alfred 🌱 was born.
Alfred is a Slack bot. *Slack bots have been around for as long as Slack (2013) and tend to be quite useful when used correctly.
*When creating a Slack bot for your team, it needs to be internally coded as there are not many readily available open source offerings that allow an extensive amount of integration and customization. We experienced this while gathering Slack bot requirements, and ultimately decided that it would be best to write our own.
Alfred started as a quality of life tool for me in DevOps and infrastructure automation. Instead of running Jenkins builds through the command line or the web interface, I could now send Slack messages to Alfred and have him handle it for me! I could also run backups and updates to our services using the same methods. This helped to improve my workflow, and allowed our other developers to run builds and tests from Slack instead of our internal services.
After a few months of using Alfred strictly for DevOps related tasks, I decided to add simple business intelligence calls to Alfred. Alfred’s first task was to look up the number of project submissions waiting in the queue for Mimir Classroom and locate specific users with details on how they used the platform.
Alfred’s functionality expanded again when I showed the initial business intelligence calls to the head of outreach to see what else could be pulled for that team. In the following week, I rewrote Alfred to allow other developers to easily add new functionality. His data analysis was polished and reported metrics through Slack in a digestible way. I added functions to find users and their attributes, including linking our CRM, support tickets, and platform usage statistics all into a single place. At that point, Mimir’s outreach team could request and receive any information on a given user or account in seconds.
Alfred continued to do more when additional commands were added, and has transformed into a frontrunner of information that nearly everyone on Mimir’s team uses daily. What started as a personal tool for making my life easier ended up becoming a company-wide force multiplier. Alfred’s features and functionality continue to evolve, increasing efficiency company-wide.
Internally coding a tool is rarely necessary, but in this case, I think every startup should have their own ‘Alfred’. Only your team fully understands the power of your company’s data. These team members are the only ones that can connect all of the data from every source to a single point. With all of this put together, your team can create a powerful tool that anyone can use, that will positively impact the bottom line.
Read more content like this at:
