In my years at Atomic, I’ve noticed some patterns across different projects. For many of them, the differences tend to fall along a very specific axis. Of course, there are technical differences in tools and platforms, but right now, I want to talk about the broader element of how the projects fit into the business.
My train of thought was inspired by Jeff Patton’s post on user experience. Jeff splits projects around whether users choose or are compelled to use the software, and whether they’re intended for internal use or commercial sale. This is a good way to partition the world for discussing the relevence of user experience, but there are other useful attributes as well.
Here are a few classifications that I’ve found useful. Each of these categories has something that makes projects easy and something that makes them hard.
Internal Business Support Software
The main challenge I’ve found when working on internal software for an existing business is the complexity of the business. With consumer software, processes are often simplified because consumers don’t need to learn every bit of errata about your business. But internal software is often a reaction to business processes defined elsewhere, so those processes cannot be simplified. There are tons of exceptions and edge cases, and you need to deal with every one of them.
To mitigate the risk of that complexity, these projects typically need a full-time subject matter expert assigned from inside the organization. This person needs to represent the business, so they probably can’t come from the IT department. They need to come from the department that will be using the software.
Internal projects usually don’t need to run so fast on the platform updates treadmill–their users aren’t expecting the latest and greatest. You can plan on dedicating around 10% of your initial development budget each year updating your dependencies to the latest long-term support release, but you probably don’t need to invest in major upgrades more than once every couple of years.
The incremental hosting costs of adding this new project are typically low, as the enterprise likely already has its own IT staff and servers. However, the calendar timeline is often long as those resources are coordinated.
The Startup Searching for a Business Model
Because this business isn’t fully known or defined yet, its process and software can be updated together (rather than the business dictating the software, as above). The business representatives can safely focus on selling the product instead of being attached to the project full-time. A development team member can be effective as the product owner for the project, answering questions for the team and connecting regularly with the customer.
User research can be a great help for these projects, as needs are typically not well-known upfront. Visual design and branding are also huge as you work to define who the startup is and what they do for users.
Hosting costs are cheap due to low user numbers. However, it’s usually your development team doing all the operations work, so expect to use up to 10% of your development capacity to plan deploys, run backups, stand up new development environments, etc. Remember–you don’t have a helpdesk, so a lot of support requests are going to go straight to the development team. That’s ok, as long as you’ve planned for that capacity.
I never recommend upgrading every single time a dependency is updated, but this is a case where it makes sense to at least review more frequently. Spreading that cost out over the whole timeline of the project may be an advantage, because when you do need to respond to a market need, hit a deadline for an industry event, etc., you’ll be able to move quickly. Instead of the annual cycle described above, you’ll want to sign up for your platform’s announcement mailing lists and determine what needs to be done as needed.
Obviously, you still need to plan for some annual maintenace costs going forward…but you can focus on building a sustainable business before you worry about that.
In my opinion, devops is very valuable everywhere, but it’s especially valuable here. It can let you onboard a new developer much more quickly, and that is a huge competitive advantage. It also helps you respond to users more readily because it’s easy to replicate the production environment to diagnose problems. Enterprise software can get a lot of mileage out of that too, of course–but the enterprise often moves slowly enough that it’s not that big of a deal.
The Big Splash
An interesting “in-between” class of project is the well-funded project working toward a well-defined 1.0 release. This is the project where you’ve built prototypes, put them in front of real users, validated and refined the business idea, secured letters of intent from major customers and channel partners, and now you just need to keep the team moving and stay out of their way.
The business should be out selling the product most of the time here, so a product owner on the development team can take the lead. Check in during each sprint, stay connected for questions, and let the team make the magic happen.
For maintenance, invest some at the end of your first release cycle. You shouldn’t need to chase upgrades much. By the time you’ve done enough research to be in this mode, you know what you need to build and what tools you need to build it with.
One key question to ask here is “What’s next?” You need to figure out your long-term plan for ongoing development. Long-term maintenance and version 2.0 often won’t be able to justify the team size you used to get to 1.0. If you’re planning to bring the development in-house after release, you need to start your hiring process about half-way through the development cycle. That way, by the time your new resource is available, there will still be some time to train that person with the team.
Hosting costs here are going to be higher because you have actual users, but you should still plan on the development team spending time on operations work.
The Native Mobile App
Almost every single mobile app that we’re involved in has some sort of web component. These apps usually have a tightly integrated server-side component, and that part has all of the risks and other characteristics mentioned in the category descriptions above.
The product owner role can usually be handled by someone on the development team, since a mobile app is typically tightly focused on some very specific domain.
However, there are additional considerations for mobile apps–namely, the app store. Apple’s App Store takes days to approve apps. Android is better, but Google recently instituted a review process.
The impact is twofold: First, you’re at their mercy when trying to patch a bug. This means that automated testing, exploratory testing, and customer reviews are even more critical than usual. A web app is often easy to patch with a simple “cap deploy,” but an app store submission is more time-consuming.
The other concern is that the third party store’s standards may exclude your app. In particular, Apple will not let you in the App Store if you’re building for an iOS version that is too out of date. If you discover a bug in a year, you will need to pay for the fix *and* for an iOS upgrade. Because of this, you should plan for an annual effort investment of around 10% your initial budget.
Everything Else
These descriptions aren’t perfect or complete models, but they do represent project patterns that I’ve seen over and over. Every kind of project has extra costs beyond just building the thing. There’s never going to be a cookie-cutter template for every project, but hopefully my experience can show you some common risks to watch out for and mitigate on your next project.