When a Startup Should Customise for a Large Customer

A large customer can give a UAE startup cash, access to a real operating problem and a reason to build something it might otherwise miss. The same deal can make the startup responsible for a version of the product that only one customer uses. Before saying yes, decide which parts solve a problem the wider product should handle, which parts the customer should fund separately and which obligations the team can support after launch.

Imagine a Dubai startup selling production scheduling software to industrial operators. A prospective Abu Dhabi customer wants to use it at several sites. The buyer asks for its own approval sequence, a connection to an existing planning system and a daily report in a particular format. These requests may look like a single requirement on a purchase checklist. They create different kinds of work. The approvals might be reusable, the connection might need a defined integration, and the report might be a temporary operating preference. Unpack them before putting a number or a delivery date on the deal.

Find the requirement underneath the request

Ask the buyer to show the work as it happens today. Who starts it, who approves it and what happens if the step is missed? Ask whether the requirement comes from a contract, an internal policy, a system dependency or an existing habit. Bring in the people who will do the work and the person who can approve a change. The person who asks for a field may know the current form, while another person can explain why it exists and whether the product can meet the need another way.

Write the acceptance condition in terms of an outcome. For example, a shift supervisor must review a schedule change before the planning team publishes it, and an authorized user must be able to see who approved it. That leaves room to design a reusable approval rule. A request to copy the buyer's exact menu sequence might reproduce how one team works without addressing the reason it works that way. Show the buyer an alternative and test whether it meets the condition before agreeing to build.

Check whether the same problem appears elsewhere. Look for recent conversations with similar operators and what they were willing to do about it. An Abu Dhabi Investment Office reel promotes Make it in the Emirates. Industrial gatherings can help a founder meet people who can explain how their sites handle similar work. Ask about the outcome and who owns it rather than showing a design and inviting agreement. Keep the research separate from any claim that other customers will buy the feature.

Choose the smallest kind of change that fits

Separate changes to settings, work at the edge of the product and changes to the shared product. A configuration option could let the startup choose which role approves a schedule at each site. An integration could map a customer's data into a defined interface without changing the product's internal workflow. A shared feature could add approval records for all customers who need them. A separate code version carries a different burden because bug fixes, releases and tests may have to be repeated for that customer.

Microsoft's multitenant architecture guidance describes feature flags that can expose new functionality to a subset of tenants. That can help the team roll out a shared feature cautiously. It still needs to test the combinations it supports and decide when temporary settings will be removed. Keep access control separate from release toggles. If the customer must be unable to see another site's data, design and verify that boundary as a permissions requirement. Microsoft Azure multitenant update guidance

Prototype the risky boundary first. For the planning-system integration, ask for representative records and a test route under agreed permissions. Check how changes, duplicate messages and outages would be handled. Confirm who can change the customer's system and how much notice the startup gets. If the buyer cannot provide that access yet, quote discovery or describe the dependency and its effect on delivery. A detailed estimate based on a sample file should remain conditional until the interfaces are understood.

Compare the deal with the work it displaces

Start with committed revenue and identifiable costs. Use the contractual minimum the buyer would actually pay. Keep possible future sites, referrals and publicity in a separate column until the customer has made an appropriate commitment. Estimate build, deployment and ongoing support in the same period. Include technical review, security checks, training, monitoring and the time spent answering questions during releases. Show what the team would have to stop or delay to do the work.

Suppose the Dubai startup considers an illustrative first-year offer of AED 240,000 in subscription revenue and AED 60,000 in implementation revenue. Direct estimates are AED 100,000 for the build, AED 35,000 for deployment, AED 45,000 for support and AED 20,000 for infrastructure. That leaves AED 100,000 against the specified costs, before sales expense, overhead, tax and the impact of delaying other work. If the integration needs another AED 35,000 in build work and AED 25,000 in ongoing support, that balance falls to AED 40,000. The terms and cost estimates are hypothetical. Use the range to identify which assumptions deserve investigation before the team commits.

Cash timing needs its own view. A payment due after acceptance can arrive well after the startup has paid engineers and started integration work. Build a schedule for spending, invoices and expected receipt. Check how acceptance can be demonstrated and what the agreement says if the customer delays access or testing. A project can have positive expected contribution and still leave the startup short of cash during delivery.

Review concentration after the deal. If most of the team's available build time goes to one account, identify the roadmap changes and support promises that other customers will feel. Look at how that changes if the large buyer renews, expands or leaves. A signed implementation can fund a useful capability. It can also take months away from a product improvement that several existing customers need. Compare the choices at the same point in time and state which outcomes are still uncertain.

Run the numbers for a smaller offer as well. One site using an export can show whether approval and reporting matter before the team connects the customer's planning system. Agree what the trial can establish and which questions it leaves open. Ask the buyer whether a successful result would trigger a purchase review and who would attend it. If the customer needs every integration before anyone can authorize a trial, account for that dependency and use a separate discovery stage to improve the estimate. The startup can then price the work with a clearer idea of what it is taking on.

Put scope and future rights in the agreement

Make a short record of the behaviour the customer will receive, the systems it depends on and who provides the inputs. Describe acceptance tests in a way both teams can repeat. If the report is a deliverable, specify its fields, timing, approved source and what happens when a value is missing. If the product needs to support multiple sites, state which sites are included and what it takes to add one. A single word such as integration rarely gives the engineering team enough detail to agree a deadline.

Define how changes are priced and who can approve them. A buyer might raise a new requirement during testing, or a vendor might alter the interface. Agree how to separate a defect in the promised scope from additional work. Keep unresolved changes out of the original completion test unless both sides agree to revise it. Set a support owner, response window and service end or renewal condition so the commitment survives a change of staff.

Have the actual agreement reviewed for intellectual property, reuse, confidentiality, data access and the effect of any exclusivity. If the startup wants to offer a general capability to others, make sure it understands what it can reuse and what belongs to the customer or a third party. Reference rights are a separate decision. If the buyer has not authorized use of its name or results, keep that potential value out of the base case.

Dubai Future Foundation describes Dubai Future Accelerators as bringing startups together with private and government organisations on defined challenges. The example is useful for founders considering bounded collaboration in Dubai. Set a problem, scope and evidence standard for the experiment, then identify who can approve a separate purchase or wider rollout. An accelerator or a proof of concept can provide evidence without establishing a commercial commitment. Dubai Future Accelerators

Keep the implementation from becoming a permanent exception

Before shipping, give the team a record of where the behaviour lives and how it is tested. If it is configuration, document the allowed values and default. If it is an integration, record dependencies, monitoring and how to recover failed jobs. If it is a temporary feature flag, give it a named owner and review date. A new engineer should be able to see which customers depend on it and which checks are required before changing it.

Test an ordinary release after the custom work is active. Check that another customer can still use the default path and that the new customer receives the contracted behaviour. Use agreed data and verify how an error is detected. If an operator has to intervene every time the external system sends an unexpected value, put that effort into the support review. It is part of the cost of the deal and may point to a simpler design.

Review the deal after the first real operating cycle. Compare actual build and support time with the estimate. Confirm whether the buyer achieved the accepted outcome and which parts could be used by another customer with similar needs. If an exception is no longer necessary, agree how to retire it. If it is likely to continue, assign maintenance and include the cost in renewal pricing.

For the hypothetical scheduling startup, a workable answer could be a reusable approvals feature, a separately scoped integration and a time-limited report. The buyer gets a path to the outcome it needs, and the startup has defined tests and responsibilities for each piece. Approve the change only when the customer commitment, the economics and the work of supporting it can all be explained at the same scope.