As micropreneurs we are always working. Even on my ‘days off’ I’m on the couch with my laptop working on code or business issues. Businesses with lots of staff have the luxury of ‘someone else will handle that’, in our world we are that someone else. So being able to work effectively and efficiently on the go is important, with the rise of smartphones and apps this is a very realistic option.
Over the last few months I’ve started collecting apps on my iPhone\iPad to help me keep in touch with my business when I’m away from the house. My business is Resgrid which is a SaaS product deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade). Serving first responder means that we can’t really have much downtime and we need to be as responsive as possible, both are challenges for startups.
So here are my top mobile apps for micro entrepreneurs to run our businesses, respond to issues and keep tabs on everything on the go.
Cloud Magic has replaced my default email apps on mobile devices. It’s a free app that connects easily to Microsoft’s Exchange (Outlook 365) and much more. If you sign up for their service it will sync your email settings and accounts to all your devices. I like it for it’s clean interface with helpful color hints. I can easily see all my email from multiple boxes and work through them quickly. Overall the CloudMagic seems much faster then the default email clients.
Quicklytics (http://escoz.com/quicklytics/index.html) FREE (IAP $9.99)
Quicklytics is a great mobile app for monitoring your Google Analytics account. View multiple date ranges, active visitors, multiple Google Analytics accounts (I have it tied to 2 different Google accounts, one personal and one business). The app looks great on iPad’s as well, gives a nice display and uses the extra screen real-estate very well. I use Quicklytics a lot to determine how marketing efforts are going on the go.
Azure Management FREE (PRO $0.99)
Resgrid is built entirely on Microsoft’s Azure platform, so being able to monitor our Azure instances and platform on the go can be extremely helpful. I’m using the PRO version, but for 99 cents it’s a great deal. At this point there isn’t any nice charting, I would love to see my load/response times on the fly, but you can do pretty much anything else for Azure Websites, Azure Cloud Services, SQL Databases, Storage and more. I use it to check the heath of my cloud service web and worker roles, reboot an instance if needed, I can even scale from the app.
TC (Team City) Companion (http://teamcitycompanion.github.io/) $2.99
Here at Resgrid we utilize Team City on our backend, for CI, deployments and even production monitoring. You could say that Team City is our back of the house catch all system. All of our deployments are automated and failing builds and tests can have a huge impact on our deliverables. The TCCompanion app is amazing, I can kick off builds, monitor runs and history, visual failed/successful builds, look at the logs and more. Doing this from my phone, on the go, allows me to kick of staging and production deploys and keep tabs on production all from one app.
While we use Google Analytics for our public facing analytics we utilize MixPanel for pretty much everything else. MixPanel is a great and very powerful analytics platform we utilize it for our product interfaces (the website after you login to Resgrid and all of our mobile apps). This allows us to see what features are being used. Quixpanel allows me to see our MixPanel analytics on the go, spot trends and view reports so I can correctly communicate what’s being used in our system. Nothing beats good, actionable, analytics for business owners.
Slack (https://slack.com/) FREE Apps (Service may cost $)
Slack is a communication service, but it can be way more then that. With the integrations is has to services like Trello, BitBucket, GitHub, etc Slack can be your core information repository. Say you pipe system notifications though Slack and a system goes down. Now you have one location where your personnel and meet to work on the issue, no more trading emails, keeping people on the loop, loosing information or getting out of context. The slack app gives you a great interface to work with Slack on the go so you avoid degrading to email.
These 6 apps have helped me be productive on the go from my phone. If I start using any more I’ll make sure to post them.
Every day I get exposed to different architectures and designs for systems. It’s a great contrast to see how a large company tends to have pretty complex software architectures compared to software I’ve designed outside the large company environment. There are many reasons for this, some of it is developers trying to show off, justifying their jobs, create job security, trying to be too clever or trying to be too helpful. Maybe the use cases or requirements were over engineered planning for every “What if” scenario under the sun.
The vast majority of the time it’s not malicious or has even a hint of bad intent. But most of the time on the developer side it’s science experiments that turned into production code or developers trying to make something too “pit of success’ie” without contemplating the drawbacks.
Complexity carries a heavy burden that most developers don’t want to think about and instead look at architecture as the solution to every problem. But too often when simple problems are over engineered it causes more problems down the line. For a large company, this is ok, they can take the extra time, throw the extra money at it or add manpower. For a startup, especially a bootstrapped startup our best feature is agility, and if our software is too complex to be agile we are trying to win a marathon with our legs tied together.
What are some problems that arise from the dark art of architecture and complex system design and why are they bad for startups?
1. Complexity make debugging more difficult and tracing issues more problematic. The more complicated your system is, the more layers it has is more you will have to debug at 3:42 AM on a Tuesday morning when the production system seizes up. When you’re in a startup environment there usually isn’t a DevOps team to deal with those issues for you at odd hours.
2. Complexity creates friction to change. The more complexity the more you need to refactor or recode when you change directions. It’s also more time, and effort you loose when you throw away that system. You will be throwing away code, and lots of it over the life of your startup. When you go in add a new feature or recode something you can then go in and refactor.
3. Complexity systems take more time to code. In a startup environment the easiest, quickest, hacky, ugliest solution is almost always the right choice. The less time you spend on things the quicker you get stuff done and to your customers getting feedback. Delivering is the most important thing. This isn’t to say you should push out totally buggy unusable systems, they need to work.
4. Architecture is not a deliverable. In the vast majority of cases this is true, but there are cases where this may be false. If your designing a system to say show people how to cook, your users don’t care how may layers you have, how you got CQRS and async full stack with DI and 100% coverage. Are those cool things? Yea, but they aren’t as important as us developers like to think they are.
5. It’s hard to bring new developers into complex system. In a startup environment development is probably one of the least valuable things you can do. As a founder you probably need to spend more time on business development, customer acquisition, planning features, marketing, etc. So you’ve reached that point and you want to bring in a technical founder, consultant or employee, the more complex your architecture the harder it will be for the new people to learn and longer it will be before they are up and running efficiently.
I’m not ‘anti-architecture’ or ‘anti-patterns’, instead I’m of the mindset that there is a time and a place for science experiments, architecture and complexity but rarely are those good for your early stage startup. I’m still trying to fight my inner architect when I develop for my startup, it’s difficult, but next time I’m up at 3:42 AM debugging an issue I’ll be a little more happy.
In this highly interconnected world our products or services rarely operate in complete isolation. We rely on 3rd or external parties for services or logic that we’d rather no do ourselves, well at least most of us. When I first started in software development I always did it myself. “My solution will be better, it will be exactly what I need, my implementation will be more flexible, etc, etc, etc” those thoughts would always come up when I needed something outside the domain of what project I was working on.
Now days, I look for external products or 3rd party solutions that meet the 80% rule. “Will this product/solution meet 80% of my core needs?” If it does, I jump on it. I’d rather spend my time taking the product or service the last 20% (which probably has more value to my business) then coding the entire thing. You might be able to build a better wheel, but should you try? When your trying to build a while new vehicle should you spend your finite amount of time and energy on it.
Because of this my products usually have a good number of external integrations, but that brings risk along with it. What if the service shuts down? The API changes? They pivot into something completely different. What happens when the stop supporting the product or code base? So what do you do? As my friend Dale would say, “That’s an uptown problem” and for the most part I agree with him. You can’t see into the future so how can you really mitigate that risk without waiting a whole lot of time.
Although it is a “Uptown problem” it can very quickly and without notice become a “it’s in your house” problem. As it did for us at Resgrid which is a SaaS deployed on Microsoft Azure, providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in late 2012 by myself and Jason Jarrett (staxmanade).
So what should you do before hand? Here is our list of data you should collect when you intergrade a 3rd party solution into your product.
- Research alternative services/products and compare contrast it with your current solution. This will help you identify other potential external 3rd party migrations. Keep the list short, at max the top 3 other solutions, but elect the ‘Plan B’ option and have some additional information on it compared to the others.
- Spend an hour and determine if it could be done “in house” and how much time and effort would be required. Determine the high level work that would need to be done and how it may be composed.
- Is it possible for your product to work without the service? If so can you turn the feature off easily to hide the issue. Do some brainstorming and have a plan of action if this is the case.
Share your findings with the team to build up some institutional knowledge then store it in a wiki or central documentation location. When you may need this knowledge it could be without notice. For us at Resgrid, we discovered an issue sending SMS gateway email’s to AT&T customers during our standard Friday deployment. Customers not being able to receive text messages from Resgrid is a big deal so we investigated and decided that we needed to implement Twilio. A day latter we had a working solution in production and our AT&T customers hopefully didn’t notice any issues. Because we had been investigating Twilio already we had some institutional knowledge built up and could implement it quickly.
If we didn’t have the knowledge built up, we could have wasted a lot of time researching alternatives, putting hacks in place and possibility making it worse. Just because something may be an “Uptown problem” doesn’t mean you shouldn’t invest some time now to help easy pain in the future.