How to describe internal tools and confidential work on a resume

Describe an internal tool by the kind of system it is, in the words an engineer at another company would use. Compare it to a public product where the comparison is fair, and give its size through who depends on it and how much goes through it. For confidential client work, name the industry and region instead of the client, and use ranges where exact figures are private.

If your best work is on platform tooling, bank systems or client projects that nobody outside the company has seen, all of this applies to you.

How do you describe a tool nobody outside the company has heard of?

The reader does not know what "Hermes" or "the BRB service" is, and probably will not ask. Replace the internal name with the category of system.

Before:
- Rebuilt Beacon and migrated all teams to Beacon v2

After:
- Rebuilt the internal feature-flag service (similar in scope to LaunchDarkly) and moved 14 product teams onto it

A comparison to a public product places the work quickly. "An internal deploy platform, like a small Heroku" gives the reader a picture they already have. Use it only when it is fair: if your flag service does on/off toggles for one app, say that and leave the vendor out, because an interviewer who knows the product may ask which of its features you built.

Name the public technologies inside it. If the service is written in Go, stores flags in PostgreSQL and pushes changes over gRPC, those names are not secret, and they are what a technical reader scans for.

Some internal names are known outside the company because the company wrote about them on its engineering blog or released them as open source. In that case you can keep the name, with the category next to it: "Kestrel, the company's open-source job scheduler". If the only public mention is your own LinkedIn post, treat the name as internal.

Show the size with users, volume and adoption

An internal tool has no public users or revenue, so show its size with other facts:

• Who depends on it. Teams, engineers, services, or internal users such as support agents or analysts. A tool 40 support agents use every day is real work and deserves a bullet.
• How much goes through it. Requests, jobs, builds or deploys per day.
• What it replaced. A spreadsheet, a manual release step, a vendor contract, an older system that was shut down.

For platform and developer-tooling work, the most useful numbers are about other engineers' time: CI duration, time from merge to production, how long a new service takes to set up. Adoption matters too. Teams that moved to your tool when they did not have to is a stronger signal than a mandate, so say which it was.

Here is a whole role built from internal work. Each bullet names the system, its users and its effect:

Halvard Payments, London
Platform Engineer | Feb 2021 – Present
- Built the internal service template in Go and Terraform; a new service goes from repository to staging in one afternoon instead of three days
- Rebuilt the internal feature-flag service (similar in scope to LaunchDarkly) and moved 14 product teams onto it; 9 of them switched before the old system's shutdown date
- Cut the median CI run for the payments monorepo from 31 to 12 minutes with remote build caching
- On-call for the deploy platform, one week in six

When ten engineers built the tool, say which part was yours. "One of four engineers on the deploy platform; wrote the rollback controller" is more believable than claiming the whole system.

Our lead backend engineer resume example applies the same idea to a product the reader has never heard of. These are two bullets from its Arctic Cloudware role, copied from the example page:

Arctic Cloudware, Stockholm, Sweden · 2015 – 2018
Backend Engineer
- Built REST APIs and Node.js services for a B2B invoicing and reconciliation platform used by 200+ enterprise clients.
- Added SEPA and SWIFT payment processing and rewrote the matching job, so daily reconciliation finished in 25 minutes instead of an hour.

Resume example

Lead Backend Engineer Resume Example

The Arctic Cloudware role describes an unknown product by what it does and who uses it

View the full example

"Invoicing and reconciliation platform" is the category and "200+ enterprise clients" is the size. SEPA and SWIFT are public payment networks, so they tell a fintech reader what you know without revealing anything.

How to describe client work you cannot name

At agencies, consultancies and outsourcing companies, and on contracts with banks, the client is often confidential. Describe it by industry and region, and add a size band if that is still vague enough.

Before:
- Worked on a project for a major client

After:
- Rebuilt the account-opening web app for a UK retail bank in React; drop-off at the identity check fell from about 30% to 18%
- Led three engineers on the React Native rewrite of a European insurer's policy app

Some engineers write "tier-1 bank", meaning one of the largest banks in a country. "One of the five largest UK banks" is clearer for international readers, if your contract allows you to say that much. Every detail you add makes the client easier to identify, and a bank described by its head office city and customer count is often as clear as its name.

If a reader could find the client with one search, you have named it.

The senior site reliability engineer resume example shows client work with no client named at all. Its RedCloudOps bullets talk about "client onboarding" and "client incidents", and in the same role it standardized CI/CD for "18+ containerized internal tools". For UK contract entries, our post on the IT contractor CV covers how to head an entry when the client cannot be named.

Ranges, ratios and public numbers instead of exact figures

Engineering numbers are rarely the sensitive part. Latency, build times and deploy frequency say little about a business. Revenue, payment value and customer counts are different, because they are what competitors and investors would want to know.

When the exact figure is private, give the size another way:

1. A range or a floor. "8–10M transactions a day" or "over 5M a day" instead of the exact count.
2. A before and after, or a ratio. "Halved the cost of the nightly batch" hides the amount.
3. A figure the company has published. If the annual report says 2 million customers, you can use that number, as long as your system really served those customers.

Before:
- Processed £1.84bn in card payments in 2023 through the settlement service

After:
- Owned the card settlement service: 8–10M transactions a day in 12 currencies

We recommend the range or the floor in most cases, because it shows the order of magnitude and you can discuss it in an interview without the exact value. For finding numbers in the first place, see resume bullets without metrics.

What is usually safe to state, and what is not

This depends on your employment contract or NDA, and they differ. Read the agreement you signed. If you still work there, the company's engineering blog, public GitHub organization and conference talks show what it has already made public. For anything still unclear, ask a lawyer.

Normally fine:

• Your employer's name, your titles and dates.
• The technologies you used and the kind of system you built.
• Your own role: what you designed, owned, led or fixed.
• Anything the company has published.

Normally not:

• Clients, partners or customers the company has not named publicly.
• Unreleased products, project code names and launch dates.
• Unpublished revenue, pricing and customer counts.
• Security details: vulnerabilities, how fraud detection works, internal network layout.

Some cases are stricter. At a startup in stealth mode, the product itself may be confidential, so describe the technology and your role and leave out what the product does. Defense and government work done under a security clearance often has its own review process for anything you publish; ask the security officer what applies. If your company has since been acquired, its old internal tools may now be described publicly by the new owner, which can make them easier to name.

What to keep for the interview

Treat the resume as a public document. Recruiters forward it, and it can reach your former client's competitors. Write it at the level of detail you would use in a conference talk.

The interview is where you add depth about your own design decisions: why you chose event sourcing for the ledger, or how you made the retries safe. The interviewer has not signed your agreement, so the same limits apply in the room.

Prepare before the interview. For your main project, draw the architecture with generic boxes such as "payment provider" and "core banking system", and decide which numbers you will use. If someone asks for the client's name, say once that it is confidential and go back to the technical part.

How to show work when you cannot show the code

Code you wrote as an employee usually belongs to your employer. As a contractor, it depends on the intellectual property clause in your contract. Either way, do not copy work code into a public repository, even with the names changed.

Other ways to show the same skills:

• A launched app, public API documentation, or an engineering blog post or talk you gave about the system.
• A small project written from scratch on your own time, in a different design from the one at work, and listed under Projects as personal work.
• Open-source contributions to the tools you used at work.

Projects
Flagpole (personal project) | Rust, SQLite
- Feature-flag server with percentage rollouts and a small admin UI; about 2,000 lines

Many backend, platform and fintech engineers have no public portfolio. Clear bullets and a prepared design discussion are usually enough.