Why they’re different games — and building one like the other is how projects fail
By Steele Consulting
A common conversation with a new client goes like this. The client tells us they need “custom software.” We ask what for. They describe a system that turns out to be either:
- A tool their team will use to do their jobs (internal software), or
- A product their customers will interact with directly (customer-facing software)
These sound like the same conversation. They’re not. In our 24 years at Steele Consulting building both types, we’ve watched the same pattern over and over: businesses that treat internal software and customer-facing software as the same discipline end up building one of them like the other — and both failure modes are expensive.
Build an internal tool with customer-facing polish and you’ve spent $400K where $80K would have done. Build customer-facing software with internal-tool assumptions and users churn out silently, taking your revenue with them.
This post is about how the two are different, so you can build each one as the game it actually is.
Why the distinction matters more than most operators realize
The reason this trips up leadership teams is that at the surface level both look identical: you commission the software, engineers build it, users interact with it, the business runs better afterward. What differs is nearly everything else — who the users are, whether they’re allowed to leave, how they judge the product, how you find out it’s failing, and what “success” even means.
Six dimensions matter most.
The 6 dimensions where they diverge
1. The Audience
Internal users are captive. They have to use the software because their job requires it. Customer-facing users are voluntary. They will leave the moment the software is more painful than the value it delivers.
This one difference cascades into most of the others. Every design decision, every feature trade-off, and every engineering priority looks different depending on whether the user can walk away.
2. The Onboarding
Internal users can be trained. You can run a two-hour session. You can require the software as part of the workflow. You can hold people accountable for using it correctly.
Customer-facing users cannot be trained. They will not read the docs. They will not attend the webinar. They will decide within 30 seconds of first contact whether your software makes sense, and if it doesn’t, they will close the tab and never come back.
This is why customer-facing software costs more to design and less to document. Internal software is often the reverse.
3. The Design
Internal software can be dense. Twenty fields on a screen is fine if the user works with that screen fifty times a day and knows what every field means. Speed and workflow-optimization trump aesthetics.
Customer-facing software must breathe. Every element on the screen has to earn its place, because every element is a decision the user has to make in the first five seconds. Aesthetics matter, not because customers are shallow, but because clean design is how trust gets built in the first impression.
Building an internal tool with customer-facing whitespace slows your team down. Building customer-facing software with internal-tool density loses you the customer.
4. The Failure Mode
When internal software breaks, someone gets annoyed. Work stops for an hour. IT is called. The bug gets logged and eventually fixed. The team survives.
When customer-facing software breaks, someone leaves. Sometimes without saying why. Sometimes with a public negative review that costs you future customers you never met.
Downtime and defects have different weight in each context. The uptime target for customer-facing software is often an order of magnitude higher than for internal tools — and the investment required to hit it is proportional.
5. The Feedback Loop
Internal software has instant feedback. Users are down the hall. You can watch them use it. They will tell you what’s broken because their job depends on it.
Customer-facing software has invisible feedback. Customers don’t tell you why they left. They just leave. Which means you have to instrument the product itself to capture what humans won’t — analytics, session replay, funnel analysis, cohort tracking. That instrumentation is a real engineering investment, and internal tools rarely need it.
6. The Scale Curve
Internal software has bounded scale. However many employees you have, that’s how many users. Growth is linear and predictable.
Customer-facing software has unbounded scale. A viral moment can 10x your traffic overnight. A launch can bring a wave you weren’t ready for. Which means customer-facing systems have to be architected for elasticity in a way internal systems never do — and paying for that elasticity for an internal tool is money burned.
The two traps
Two failure patterns show up repeatedly. Both cost real money.
Trap 1: Building internal software as if it were customer-facing
The team spends $400K on beautiful design, cross-browser compatibility, mobile responsiveness, and 99.99% uptime — for a tool that thirty employees will use during working hours. The polish doesn’t deliver ROI. The team could have shipped a workable version in a quarter of the time for a quarter of the budget, iterated based on user feedback, and had a more useful tool a year later.
Trap 2: Building customer-facing software as if it were internal
The team builds something that assumes users will “figure it out.” It has twelve setup steps, a dense home screen, and no onboarding flow. Users bounce before they see the value. The team blames product-market fit or the marketing. The actual problem is that the product was designed for users who don’t exist — trainable, patient, captive users.
Trap 1 wastes money. Trap 2 loses businesses. Trap 2 is the more common one for growing companies who’ve built successful internal tools and assume the customer-facing version will follow the same playbook. It won’t.
What stays the same for both
For all the differences, one truth holds for both: any software your business commissions is software your business is now responsible for maintaining. Forever, or until you consciously kill it. This is the point we made in How to Kill a Software Project Before It Kills You — the ongoing cost of software is often larger than the build cost, and internal vs customer-facing doesn’t change that.
The DRIFT framework from our tech debt post applies equally to both. So does the Build, Buy, or Bend question — before you build either kind, the question of whether you should be building at all is the first one.
How this connects to the other decisions you’re making
The internal vs customer-facing distinction sits underneath several of the other frameworks in the cluster. When you’re running the Build Score from Build, Buy, or Bend, the “customer-facing impact” variable is doing exactly this work — telling you whether the stakes are internal or external. When you’re evaluating a software partner using the 5 Tests and the Discovery/Delivery archetypes, the criteria weight differently: for internal software, delivery skill matters most; for customer-facing software, discovery skill often matters more, because getting the user model wrong is fatal. When you’re thinking about which kind of dashboard to build — the 4 Questions Test from our dashboards post — you’re really asking whether the user is internal (captive) or external (voluntary), which is this post’s core question.
How we approach this at Steele Consulting
We build both. And we structure the projects differently from the start.
For internal software, we scope aggressively toward speed and function. We ship rough versions, get them in front of the team that will use them, and iterate based on what people actually do with them (not what they said they wanted in the kickoff). Timeline is faster. Budget is smaller. Design polish is proportional to the number of users and the number of times per day they’ll use it.
For customer-facing software, we spend more time up front on discovery, prototyping, and user testing. We instrument the product to capture the feedback the users won’t give voluntarily. We architect for scale patterns the internal-tool version wouldn’t need. Timeline is longer. Budget is larger. Design is a first-class part of the engineering conversation, not something we bolt on at the end.
The confusion between the two is the single most common way custom software projects come in wrong — over-built and slow when they should have been fast, or under-built and unloved when they should have been polished. Getting the distinction right at scoping time saves both money and outcomes.
If you’re planning a build and you’re not sure which of the two games you’re actually playing, that’s the conversation we’re happy to have. Reach out and we’ll walk through the six dimensions with your specific situation.