--- title: The Soft Launch Conversation Nobody Wants to Have With Marketing description: Announcing a launch date too early creates real problems. Here is how to handle soft launches, slipping dates and marketing timing well. image: https://weareaffective.com/hubfs/learning-centre-images/the-soft-launch-conversation-nobody-wants-to-have-with-marketing.webp --- [Skip to content](https://weareaffective.com/learning-centre/the-soft-launch-conversation-nobody-wants-to-have-with-marketing#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # The Soft Launch Conversation Nobody Wants to Have With Marketing Table of Contents We gave the same advice to two clients within the same stretch of work. One was building a gaming app for art enthusiasts. The other was building a grassroots football product. Tease what you are making, drip-feed it, show people parts of it, but keep a launch date out of public posts until the build is confirmed ready. Both clients picked a date anyway. > A date is the one claim in a pre-launch post that your audience can check against reality. Neither date came from a development plan. Both came from a marketing plan, which is a different thing with different pressure behind it. Marketing wanted something to count towards. Product had nothing firm to hand over. The gap got filled with a guess, and the guess went out on social. What followed was predictable and still uncomfortable to sit through. Changes came in, rework followed, and the published dates passed with nothing live. Both clients had to go back and revise the day they had promised their audiences. The teaser content had done its job properly. The date undid it. ## What Actually Happened: Two Launch Dates That Moved On both projects our advice was identical. No paid social campaigns and no fixed launch date until after a soft launch had shown us the product held up with real users. Both clients decided not to take that advice. Each picked an arbitrary date, and each started drip-feeding social posts carrying it. Then the changes started. That happens on almost every build and it is usually sensible, because a working product raises questions a wireframe never does. Changes mean rework, and rework moves a date. Neither launch happened on the day that had been published. So both clients began backpedalling in public. A post explaining the new date, then later another one, each written in slightly more careful language than the last. Every revision chips away at the audience's confidence, and the paid spend behind those posts had already bought anticipation for a day that never arrived. The money was gone and the goodwill went with it. The teasing itself was fine. Alluding to the product, showing fragments, building curiosity, all of that worked. Fixing a public day before the launch was confirmed is what cost them. Before a date goes into a social post, ask one question. Has anyone outside the team completed the main task in the product without help? If the answer is no, the date is a guess. ## Why Marketing Needs a Date and Product Can't Give One Marketing plans backwards. A launch day sets the influencer briefs, the [email sequence, the press outreach](https://weareaffective.com/learning-centre/how-to-write-app-marketing-emails-that-people-actually-want-to-read), the paid budget and the content calendar. Remove the day and the whole plan floats loose. So the request for a date is reasonable, and the pressure behind the request is real rather than invented. Product plans forwards, and forwards is harder. A build is a stack of decisions that have not all been made yet, and until the last few are made nobody honestly knows the finish date. Anyone who hands over a day before that point is describing a hope. #### The sports club app We worked on a [well-funded sports club app](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), built to handle finances, games, schedules and players across several sports. We advised launching with a single sport, on a single platform, as an MVP. The client pushed back through the entire process. They wanted everything ready before anything at all went live. With that stance there is no honest date available. "Everything" has no edge to it, and a release with no edge cannot be scheduled by anyone. A team can say when a defined slice will be ready, and that client had refused to define a slice. The date and the scope are the same conversation, which is why product keeps declining to answer one without the other. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Difference Between Teasing a Product and Promising a Day Showing people what you are building is a good idea. A screen here, a feature there, some of the thinking behind a decision, a glimpse of the team. That content builds an audience and costs you nothing if the build runs long, because none of it has made a promise with a day attached to it. What we recommend instead is language that narrows as confidence grows. Early on, "coming soon" is enough. Once funding and the team are settled, "coming next year" works. When the core flows are built and tested, a season or a month becomes safe. The day itself goes public last, after the build is confirmed ready and approved. > Teasing costs you nothing if the build slips, but a published date costs you the trust you just bought. The useful way to think about each step is what has to be true before you say it, and what it costs you when the day moves. | What you say | What has to be true | Cost if it moves | | --- | --- | --- | | Coming soon | You are building it | Nothing | | Coming next year | Funding and team in place | A reworded post | | Coming this spring | Core flows built and tested with users | A short, honest update | | Live on 14 March | Build finished, tested, store approved | Audience trust and the spend behind it | ## The Real Reasons Launch Dates Slip Dates rarely slip because a developer was slow. They slip because the product being built kept changing shape underneath the plan. On a grassroots football club app, the client wanted to replicate several different apps inside one product. We tried to get them to release a couple of parts first, test the market and grow from there. The client would not have it. [Scope grew, the budget grew](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) with it, and the product never reached market because it had become complicated for no good reason. #### When the founder outranks the data On two other projects, a [fitness and wellness app](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) and a grassroots football product, the founders were very sure about what they wanted, most likely because the problem was one they had lived with themselves. Research came back. Focus groups came back. Surveys came back. All of it was set aside in favour of the original vision, and what got built became a vanity product. Both projects spent their budgets in design and build and never reached a full live version. There is a quieter cost to all of this. While the date keeps moving, competitors arrive, technology shifts and the market moves on without you. Taking too long is the failure we see far more often than launching too early. ## Warning Signs the Date Will Move Before Anyone Admits It A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products. The plan was to merge several of them into one. They were excited and pleased with themselves, and the spreadsheet was genuinely thorough work. We started asking questions about prospective users. Why pick an all-in-one over an app built to do one job properly? Does consolidating features water each of them down? By the end the founder was deflated, and we understood why. Being honest about what makes a product succeed is our job, because building on enthusiasm alone serves nobody. An ambition to merge several products into one is a reliable early sign that a date is in trouble. These are the others we watch for. - Sign-offs being rolled back so further changes can be requested - Decisions sitting unmade for weeks with no new information arriving - A push to perfect screens that no outside user has seen - Features appearing after scope has been agreed and costed - [Research findings being explained away](https://weareaffective.com/learning-centre/research-findings-from-our-own-work-where-lifestyle-brand-reorder-flows-break-do) rather than acted on If a sign-off gets reopened twice on the same screen, treat the launch date as internal information until that screen is settled for good. ## The Conversation to Have Before a Date Goes Public The conversation is short, slightly awkward, and saves months. Get marketing, product and the founder in one room before a single date reaches a public channel. Five things need settling, in this order. 1. Write down what "ready" means in plain words, with the features that are in and the ones that are out. 2. Name one person who decides that ready has been reached. 3. Set the soft launch window and agree who is going to be in it. 4. Agree the language marketing uses publicly until that window closes. 5. Decide what happens if the window moves, including who tells the audience and in what words. Most of the heat in that room comes from the fourth point. Marketing hears "no date" and assumes "no campaign". The campaign still runs. It runs on the product, the problem it solves and the people building it, and it stops short of naming a day. One more thing is worth settling while everyone is in the room. Decide how much paid budget goes out before the soft launch, because spend pointed at a date you later move is spend you pay for twice. That was the quiet cost on both of the projects we opened with, and neither client had planned for it. ## The Sequence We Now Recommend: Soft Launch First, Date Second Getting something imperfect in front of real people and improving from there is cheaper and more effective than building towards perfect. Nothing launches finished. [Bugs, iterations and new features](https://weareaffective.com/learning-centre/7-signs-your-app-has-more-bugs-than-you-think-and-how-to-fix-them) are what a living product looks like, and chasing a perfect day-one product is the quickest way to burn through a budget. 1. Put the product in front of a small group of real users, outside the team and outside the founder's friends. 2. Watch them get through onboarding without help, and note where they stop. 3. Confirm the core proposition lands inside the first sixty seconds of use. 4. Check that someone can reach first value with no friction in the way. 5. Fix what those sessions exposed, then narrow the public language by one step. 6. Announce the day once the build is confirmed ready and the store has approved it. None of that takes months. What it takes is a willingness to let people outside the building touch the product before the audience has been told anything binding. > A soft launch turns the launch date from a guess into something you have evidence for. Launching, listening to what resonates, then spending the next slice of budget on what the market responded to is a far better use of investment than chasing an ideal the original budget was never going to reach. ## Who Controls the Release Button On a social football product we worked on, the client held the App Store Connect Account Holder role, because the account had been registered in their name. They gave us admin access to the majority of the account, and we set the testing structure up carefully. One internal group for our team, one for the client, and an external QA beta group for the client's own testers. That structure let us control which build reached which group during deployment. Our team sees it first, the client sees it once it is stable, and QA sees a version prepared for them to break. Everyone gets the build that suits what they are there to do. #### What happened near launch As the launch approached, the client started going into the account and sending builds that had already been uploaded to whoever in a group they wanted. It caused problems. Because everything sat on their account, they had full access and we had very limited ability to prevent it. So the question of who presses release deserves an answer out loud, early, in the same conversation as the date. An account holder can bypass any process they agreed to, and the person most likely to do it is the person most anxious to get the product in front of someone. ## Marketing Work That Doesn't Depend on a Date We built an [anonymous messaging app](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) that required registration upfront, before anyone saw anything inside it. That decision had a consequence we had to design around. All the messaging we normally drip-feed through use had to be communicated before the app opened, so the App Store listing and the screenshots had to carry everything about the product on their own. That was a serious amount of work outside the app, and none of it needed a launch date. Store copy, screenshot order, how the product is framed, the first thing a stranger understands about it. All of it sat ready, and none of it expired when the build ran long. There is plenty of this kind of work available while the date is still unknown. - Store listing copy and the screenshot sequence - Audience building around the problem rather than the product - A waitlist with no promised day attached to it - Founder content explaining why the thing is being built - Press relationships started early and kept warm Judge pre-launch marketing on audience built and store readiness rather than on how close the countdown is to zero. ## What to Do When the Date Has Already Been Announced Sometimes we are brought in after the posts have gone out. On a grassroots football product we worked on, the founders built towards what they believed the product should do rather than what the market was signalling back to them. We advised against cramming features in. The product became so complex that development had to stop, and we ceased working with them. More than a year on from scratch, there is still no marketable product available to download. What exists instead is a run of "coming soon" posts, one after another, with the date quietly shifting each time. Every one of those posts asks the audience to care again, and fewer of them do. If a date is already public and the build will not make it, the repair is straightforward. 1. Move the language out once, to something wide, and do not move it again. 2. Say plainly that it is taking longer because of what testing showed. 3. Pause any paid spend pointing at a specific day. 4. Cut scope to the smallest version worth using, and get that version live. Audiences forgive one honest delay. A sequence of quiet revisions teaches them to stop paying attention, and that is far harder to recover from than the delay ever was. ## Conclusion The two projects that opened this article, the gaming app for art enthusiasts and the grassroots football product, both ran decent teaser campaigns. The content was good. The audiences were real and growing. The dates attached to that content were invented, and inventing them cost both clients the goodwill the content had built for them. So the conversation marketing does not want to have turns out to be a short one. Tease freely. Build the audience. Get the store listing, the press and the launch content ready in advance. Hold the day back until a soft launch has shown you that real users can get through onboarding and reach something worth having, with nobody from the team sitting beside them. The launches that stalled worst in our experience were the ones that waited for everything, re-dated themselves in public and ran out of budget in design and build. The ones that went well put something imperfect in front of real people, listened to what came back, and set the date afterwards. If you are sitting between a marketing plan that needs a day and a build that cannot promise one, that is a solvable problem and we have worked through it plenty of times. [Let's talk about your launch timing](https://weareaffective.com/get-started). This article is part of our guide to [App Planning & Strategy](https://weareaffective.com/app-planning-strategy). ## Frequently Asked Questions Why is publishing a launch date before the build is finished such a problem? A date is the only part of a pre-launch post that your audience can check against reality. Teaser content builds curiosity and nobody can prove it wrong, but a missed date is visible to everyone and forces you into public corrections that chip away at confidence. Can we still tease the product before we know when it will be ready? Yes, and you should. Alluding to the product, showing fragments and building curiosity all work perfectly well without a day attached. The teasing was never the issue on either of the projects described, the fixed public date was. How do we know when a date is safe to publish? Ask one question before the date goes anywhere near a social post. Has anyone outside the team completed the main task in the product without help? If the answer is no, the date is a guess rather than a plan. Marketing needs a date to plan everything else. Is that request unreasonable? Not at all. Influencer briefs, email sequences, press outreach, paid budget and the content calendar are all built backwards from a launch day, so the pressure behind the request is genuine. The problem is not that marketing asks, it is that the gap gets filled with a guess that then goes public. Why can't the product team simply commit to a date? A build is a stack of decisions that have not all been made yet, and until the final few are settled nobody honestly knows the finish date. Anyone handing over a day before that point is describing a hope, not a forecast. Why do launch dates keep moving even on well-run projects? Changes come in on almost every build, and that is usually a good sign because a working product raises questions a wireframe never does. Changes mean rework, and rework moves the date. Treating that as a failure rather than a normal part of building is what creates the panic. What is the risk of putting paid spend behind a dated teaser campaign? Paid spend buys anticipation for a specific day. If that day arrives with nothing live, the money has already gone and the goodwill goes with it. Hold paid campaigns until after a soft launch has shown the product holds up with real users. Our client wants everything finished before anything goes live. What is wrong with that? If the release is defined as everything, it has no edge, and a release with no edge cannot be scheduled by anybody. Launching with a narrower scope, such as a single sport on a single platform, gives you something you can actually date and defend. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.