You can’t go one day without reading that “xyz” is a new platform startup or that established market leader “abc” is now a platform company. It’s the strategy du jour, lauded by executives, sales, and marketing, but it presents an interesting challenge for CTOs, who often view themselves as innovation agents on the front lines as opposed to chief strategists.

(For those unfamiliar, a platform company is one that enables other companies to build services and/or technologies on top of its own offerings.)

No doubt your CEO has also read about why being a platform is important to startups and what partnerships can do to accelerate growth. But, how should a CTO be ready for the mandate to make a product a platform, and how should they execute the partnerships when the CEO presents the case — almost always with an unreasonable expectation of time? (No offense, Chris.)

It’s an interesting challenge to us technologists and often includes — if I’m being completely honest — a balance between tried-and-true, solid initiatives and some temporary “scotch tape and chewing gum.”

Here are six partner strategies that CTOs at aspirational platform companies should consider:

1. Know what you can fake (yep, I said it)

Let’s start with a bit of honesty. Often an “email API” suffices when starting to test a partnership, whether that’s a single company or a new partner ecosystem. A Powerpoint can stand in for a live dashboard. Many products have export and import functions, so at the minimum, can you export from your product and import into the partner or vice versa? This kind of human-in-the-loop shortcut can let the business teams test with the market and work out commercial agreements. Many partnerships don’t go anywhere, so you don’t want to write a ton of code for something that may not work out.

2. Hire picky front-end and mobile engineers

You’ve done everything right and built your API first, but your front-end and mobile engineers will be the first consumers of your API, and you want them to be picky to keep your API honest. They should aggressively push back when something isn’t clean. It’s too easy for front-end engineers to be nice to their coworkers and implement a workaround for a bug or a technical limitation in the backend. That’s just kicking the can down the road for a partner to find. It also exposes you to unnecessary questions about your nascent platform capabilities — something that already plagues many startups — especially if you’re partnering with well-established, large companies.

3. Bucket your partners

You’re likely to have multiple partners of the same type who use largely the same flow, and oftentimes this presents a unique opportunity to consolidate workstreams. When you onboard a new partner, see if it’s similar to other partners, and look to generalize the code so most of it is shared. This not only costs you less time when you’re working on the next partner but also can save you time on the next series of partners you bring into your ecosystem. On its face, this may seem somewhat simple, but it often isn’t apparent in the early stages of building a platform. You may have a whiteboard full of aspirational architecture openings for all kinds of different partner applications, but many times you may have just one company in mind for each slot. However, you can never predict when a hot, new startup will come onto the scene that would also be a fit for that slot. By bucketing your previous partners and working to generalize the code, you may be in a better position to share that code, bringing that startup onto your platform faster.

4. Write an appropriate amount and type of documentation

Any partner building an application on your tech is going to want documentation. However, you don’t want to spend a bunch of time documenting things, especially when they may change or may not be used. Here are a few tips when thinking about technology documentation:

• If your internal documentation is the same as your external documentation, there is no marginal work. Can a partner use the same documentation that a new engineer uses when they join your team?

• The business folks at your prospective partner will ask for documentation, but know your audience. What they really want is to show something to their tech team and get a stamp of approval. In that context, the tech team won’t be writing any code, they just want to make sure you haven’t done something crazy like RPC-style web services with XML. They want to make sure you check all the boxes.

• Writing documentation is easier than writing code or tracking down bugs. So don’t be shy about writing custom documentation for a partner that tracks with their use case.

5. Add partner flow to your regression tests

If you make a change that breaks your own front-end code, it’s bad, but easily fixed. If you break a partner flow, it’s a much bigger deal. It’ll disrupt your partner, take you longer to find and fix, and cause a loss of trust. Adding a flow that mirrors a partner’s usage can cut off those problems.

6. Sprint

Partnership discussions can be long, and big companies in particular will talk about many more partnerships than they’ll actually execute. The longer it takes to get something going, the greater the chance the partnership dies on the vine. You don’t want your tech team to be the reason for the delays that lead to the partnership never launching. So when the time comes, sprint as quickly as possible. One of my company’s partners does one-week “hackathons” to try to have a live partnership at the end of the week. You want to be the one that can move quickly, especially when you’re the startup.

At the end of the day (probably a long one as a CTO), the exec meeting where your CEO says, “We’re going to be a platform company” will always come with some hysteria. But it doesn’t have to unnecessarily burden your technical staff while they’re feverishly executing on your core products. As a leader, the CTO should take the wheel a bit more and use these steps to streamline the platform-partner process. We CTOs may not think of ourselves as business-strategy leaders, but it’s these types of initiatives that substantiate the “C” in our titles.

James W. Warner is cofounder and CTO of market and advertising research technology company Survata. He has more than 15 years of experience building large-scale systems at companies like Oracle and Amazon. He previously headed the software development organization for three venture-funded startups and is the inventor of 20+ issued U.S. patents.