Yes. Keep the real application on a subdomain, and make your marketing website a simple wordpress install. Minimal effort, and works great if you don't care about authorization / integration between the two.
Put the Wordpress on a completely separate server so the WordPress instance is properly firewalled from your main application/database. But don't leave it on a subdomain -- set up a reverse proxy so you can route to a subdirectory on your main domain. Better SEO. I'm not an SEO hawk, but if the point of Wordpress is marketing, then it's important.
Edit: All good replies regarding cookies. Thank you for the correction. It is not "properly firewalled". The server side code is on a different machine, but this doesn't get you "proper firewall".
If it's just part of the path on the same domain, then almost any Wordpress security vulnerability can leak over into your main application (i.e., cookies, credential stuffing, xss, etc)
Marketing site on www
Real app on app.example.com or similar
You might also consider a full web application firewall (WAF) - there are plenty including WP internal solutions, commercial and open source. Me? I slap HA Proxy on the front.
As you imply, I wouldn't bother fiddling with domain names - that is not a security solution and will bugger up the "message".
It was a horrible mess.
And not diminishing the other components, but my understanding of retail at scale from working corporate for a moment shifted to "Supply Chain is where profit is made or lost: everything else is follow-through."
I have experienced this myself personally, and have contracted with numerous companies who ran into the same issue.
The biggest issue I ran into was when the dev department started to not care about the WP instance because they don't work for marketing, and the marketing department failed to report one of their accounts was hacked, and a plugin was taken over :(
This is not really a safe and scalable solution for startups anymore.
In your scenario, the app developers create something that gains traction. But they have not spent any time writing guides, docs, or any sort of marketing content. They are only worried about their app code, and someone else will fix the tech debt eventually when they set up the WordPress blog site on a sub domain.
If the devs ever reach that point in success, they have now created a silo between the main app, and the WordPress instance. They two apps usually run out of sync in consistency and feel, and factioned teams form around who works within the app, and who works within WP on the content.
The two teams eventually get out of sync, and the users never get the basic info they need to use your app.
Then when nobody is paying attention, someone takes advantage of a vulnerabilty in a dumb WP plugin, and they spam your blog site with porn links and offensive content. Now you have to handle damage control, and closing the hole and erasing the content.
The only successful YC company in recent history I have seen pull this off is OpenSea, but I'm not even sure what they are up to today.
To the contrary, launching a startup is: 20% writing code. 80% writing docs, guides, and marketing content.
Further to the contrary, I have found that the most successful YC companies and products all started their code products with documentation.
Stripe and Shopify both launched, and immediately started building out user guides and marketing content.
The common denominator between Stripe and Laravel at launch was users commenting how easy their product was to use, and how complete and simple their documentation was to understand.
These companies didn't wait to find a content solution, they started writing their content alongside their code since day 1.
I have researched this to get the definitive, but it's difficult to find out what Stripe is using exactly. They are 100% generating their content statically though, and their user docs are dynamic with data.
It's clear that it's a monorepo that they are packaging up at build time to create a seamless website.
Any ideas on what they are using to accomplish this?
Regarding the original topic of this post, I'm 99% confident that Stripe is not using WordPress to write their docs and content either way.
P.S. On another note, I've been leaning on BDC to provide me with insight and feedback on my current project.
I really doubled down on this modern content system idea after I interviewed with Increase for a senior frontend role under Ben. They asked me to critique the frontend and tell them what I would improve. The only improvements I could find was the lack of user docs and marketing content to promote all their development efforts. It's @bdc of course, how am I going to improve his work when he is setting the bar?
Increase lacked content at the time because they hadn't yet found a seamless method of content management with their existing Vue.js codebase.
My current project solves all of this with a simple Next.js app that comes baked with everything a startup could need for content.
You may be over-indexing on “packaging”. It’s been a while since I’ve worked on docs, but much of what you’re calling “packaging” is simply routing to another app.
Coming soon to Elegant: Split your docs, React code, and blog content into seperate repos, and pack them back up into one app during build time : )
Can WordPress or Ghost do that?
I promise to all of you that I'm somewhat correct, and I have all the data to prove it.
I spent over a year doing R&D on this issue, and I found that the most successful startups were actually rolling a detached Docusaurus instance hosted on Vercel or Netlify, as opposed to running WordPress.