Congratulations, You’re a Technology Company Now

Assuming you’re like most startups out there, money is a finite resource. If you’re dipping a toe into the software product waters (or cannonball-ing right in), those limited funds seem best spent on the idea: How do we build the best thing possible? Handing the budget over to the thing being sold makes sense, after all.

As you can probably guess, that’s not what this article will aim to argue. When we’re helping a prospect or client weigh a new idea, there’s a long list of pre-project speeches to run through. Some of the greatest hits include:

• Building the application isn’t the same as marketing it
• You’ll find new requirements once it’s in front of customers
• Congratulations, you’re a technology company now

They’re all important, but that last one tends to sneak up on non-technical founders. Let’s take a look at its impact and the places where budgeting beyond development is necessary.

Your Pledge to Customers

Your product is a promise of service, but responsibility doesn’t begin and end with access to it.

Internal and External Users

First, a quick note: Sometimes, your application’s “customers” are members of your own organization. Internal tools are a valuable way to automate or scale operations, and their users — despite not being traditional paid subscribers — are owed the same level of care. So, all of the following topics all apply to internal software, too.

Handling Software Support Requests

When there’s an issue (there will be), users need a way to tell someone.

That doesn’t mean you should start prepping a call center for launch day, but some sort of process is necessary. Where do support requests go? How are they routed to the appropriate person from there? Who gets informed when there’s a fix? How quickly should fixes happen?

For many, this means setting up a third-party service like Zendesk or Zoho Desk and determining who’s responsible for what pops up. Small teams usually wind up sharing the load, and are better for it: Covering support requests is the easiest way to talk directly with real, live users — something expensive to replicate. And, it’s amazing how many customers become loyal fans after a bit of help from the founder.

We’ve lived the rush during free-of-charge Code School weekends, where pizza and gift cards were great tools to temporarily bolster our support team. In the tech industry at large, an approach of “Everyone Does Support” isn’t a new one. The process that’ll fit (and the timing to hire dedicated customer service reps) varies from product to product, but it can’t be put off without losing some early adopters.

Managing Software Feature Requests

Early product releases are a flurry of iteration and false starts.

You’ll hear a lot of feedback from users like: “This would be perfect if it just had _____.” Saying no isn’t too difficult if you hear a request once, but what happens when you hear it daily? What if a life-changing customer needs one bit of customization before they can commit or renew?

Past the fanfare of launch, customers are owed a reasonable amount of future insight on the product they’re paying for. Release notes, maintenance windows, version schedules, and (accurate) roadmaps all become part of the technology company reality.

Policies for Everything Tech

Like any other business, customer communication centers around setting expectations. How do refunds work? What’s the baseline of monthly uptime? How do you moderate community-driven features? The more contentious areas of your offering need some attention ahead of time, and should be documented.

As with feature requests, the name of the game is predictability: Can your users find these answers? Will they always hear the same answer? If not, it’s not a policy.

Your Pledge to Technology

As a technology company, it stands to reason that you’ll be putting a fair amount of ongoing effort into technology. Here are the areas that demand the most attention.

The Week After Launch

No matter how “done” an application feels on launch day, new issues and edge cases always find a way. We’re fans of earmarking a weeks’ worth of budget to tackle critical discoveries.

Best case scenario: those funds can easily be rolled back into feature development or maintenance.

Maintenance = Dependency Upgrades

Software maintenance is a spectrum. Whether you’re planning on active feature development or just keeping the thing running, managing all the frameworks, languages, libraries, packages, and third-party services in your application is a constant.

As we looked at with licensing, these dependencies can easily tally up to hundreds or thousands. They’re regularly receiving updates of their own — bug fixes, performance tweaks, critical security patches, and features that you’ll want to take advantage of. Upgrades are usually as simple as installing the new version, but there’s another wrinkle: Your application may need a bit of refactoring to match up.

Just picking these dependencies adds some danger too, since they can up and disappear. SublimeVideo (no link, which means exactly what you think it does) was a paid video player service that we used in a few projects and across all Code School courses. As it shuttered, we had to devote unplanned time towards finding, replacing, and redeploying all of the affected applications.

All that said: Planning for and handling maintenance is the biggest technology-related rock that your technology company will need to handle.

The Shelf Life of Software

Browsers have stabilized a lot in the last 10–15 years, so there’s less of a danger (comparatively) that today’s web standards will suddenly stop working out of the blue.

The bigger concern sits with quality and competitor creep. How long are you willing to rest on your laurels? Applications that led the design and experience pack five years ago feel dated today. If you’re in a lucrative market, competitors will routinely pop up, and improving on your interface is a really easy entry point.

Slack is a great example. When we switched internally from HipChat in 2013, the folks that made that decision called it a friendlier, prettier take on the same problem. The rest, as they say, is history.

Long-Term Technical Leadership

Kicking off a new venture with a full in-house team to support it is rare. Staff developers may exist, but won’t cover every specialization (UI, UX, front-end, back-end, devops, and whatever others have been added since I started writing) right out of the gate. Technology companies (remember, that’s you!) have some soul searching to do when it comes to sourcing the rest.

Even if it never makes sense to bring a development team together under your employ, a technology company needs someone comfortable wearing the CTO hat for longer-term platform vision and decision-making.

Software’s Not Just a Burden

Being a technology company isn’t all bad — its popularity would be confusing, if that were the case. As a palette cleanser, let’s talk about some of the good stuff.

Scalable Domain Expertise

Building a product unlocks the wonders of scale. Most products start with an offering that requires one-on-one meetings, a brick ‘n’ mortar location, or manual intervention, then removes that limitation. It’s a path that trades high-touch for throughput and reach.

Our work on Explore Data Science walked that path. As data science became a sought-after specialty, Booz Allen Hamilton lacked a scalable way to spread their internal expertise company-wide. Diving into educational technology hit the mark, with the added byproduct of putting their curriculum to paper.

A New Audience

As the internet melts (most) boundaries away, the globe becomes your marketplace. Who knows, maybe you’ll be big in Japan.

Attention for Whatever You Were Already Doing

Engineering as marketing is a means of promoting your services with a product or tool that gains a following of its own. Your application may hit it big, but it could also amplify something else you offer.

We didn’t plan for it, but Code School was Envy Labs’ primary means of new business leads for years. Companies came to us with plans for their own technical training platforms, or because their developers had plied their trade through our content. From an “ad” spend perspective, the returns were far more than we could’ve hoped for.

Welcome to the Club

Whether it’s a customer-facing product or an internal tool to clean up a process, launching an application means that you’re now a certified technology company. It’s an exciting line to cross (scale! audience!), but there are some new responsibilities that come with the territory.

We talk with founders and embedded teams looking to take the leap all the time. If you have any questions, concerns, or just want to talk shop, I’d love to chat.