[Offer] Let's get commercial!

Thanks for the shoutout! There are really a ton of ways to approach this, thanks to Coda’s awesome API. A couple thoughts:

  • I’d consider using Stripe’s Payment Link product instead of Gumroad, so you can avoid the additional fees that they charge. Just drop the payment link into a Coda button, and you’re set.
  • I’d consider using Coda’s “share doc” API endpoint to share doc’s with users directly, rather than allowing them to copy your templates. This feature, along with Coda’s recent support for disabling copying of doc’s, allows you to retain a lot more control over how your documents are used and opens up entirely new use cases. For instance, you could build a subscription product on top of Coda and revoke access to a user’s doc’s if their subscription lapses for X number of days.

Just some thoughts. I’m working on a larger guide to monetizing Coda doc’s, so lookout for that. In the interim, I shared some other ideas and examples on Twitter (see below). Happy building! :beers:

Today, I launched Pitch Book — a tiny product for organizing your #publicrelations workflow built on @coda_hq. Afterward, a couple folks asked about selling Coda templates. So I thought I'd share my approach. (If you want to buy Pitch Book, see the attached 🧵) #buildinpublic https://t.co/tzvaIEXzrn

— T.S. Strickland ✍️👨‍💻 (@TSStrickland1) June 23, 2021
2 Likes

HI JA

How did you go?

Interesting you want to make a fixed app on a no code site, for a fixed workflow. Something I think so greeat about Coda is is that it is so customizable. Give teams or companies horizontal flexibility and listen to them considerately to understand their needs, they likely will share differently and the end product app would be more specific to their use cases and processes.

From there I see great consulting oppotunities from those that understand taking requirements and project managment, and delivering on promises.

I dont see opportunities for building ‘the latest best app’ here that will be used over and over - even hidden tables or linked docs with ‘piece tables’ missing that support the app (like hiding the code so it can’t be resold) doesn’t seem to work here, which is why it’s great for Coda as a business and why they are sharing so many incredible templates out there

(Seems to be also as a catch up to Notion to get great use cases in the community shared for free … )

It’s trello - but docs and better - it’s too flexible.

Just my thoughts

1 Like

Thank you for your contributions re: monetizing Coda docs. For your idea above where you suggest sharing the doc via email and disabling copying capabilities, will everyone with whom you have shared via email be able to see each other’s email addresses? I can see where this could be a positive in some cases but a negative in others. What do you think is the best way to hide the email addresses of people with whom you have shared the doc? Really love your work on monetization !

1 Like

Hi there! Nice to hear from you. It’s been a minute. Typically, I’d use Coda’s Doc List pack to copy the template programmatically before sharing it with the end user. So each customer gets their own copy of the doc, and there’s no need to worry about hiding other users’ email addresses.

Obviously, this doesn’t work if your product is such that it demands interaction between different users (i.e. some kind of community-focused product like my Codex project). In those cases, you have limited options to protect user’s privacy, since this is really stretching Coda’s intended use cases.

If this is important to you, I’d suggest a couple things: First, I’d make sure user’s understand that their email might be accessed by other users. Clearly, Coda already does this, but it doesn’t hurt to reiterate it. Second, I’d make it hard for folks to access those email addresses by not exposing them directly in user-facing tables and making use of Coda’s locking features to limit access to the canvas.

Hope that helps!

1 Like

Coda has made some progress here with the Publish feature, however it is hamstrung by the fact that ‘publish/edit’ is essentially ‘share/edit’ - anyone who edits a published doc gets a link to the non-published doc in their coda.io homepage, giving them defacto ‘share/edit’, so ‘publish/edit’ theoretically is awesome but its completely broken.

My approach would have been to create a doc that is published, make every user-facing interaction specific to user(), and then have some metric that limits action in the doc. Then have a Stripe webhook/zap/stripe pack hook into the doc, so that when a payment is made it updates the metric in the doc allowing access … all the pieces are there except the publish feature is broken and Coda has confirmed they have no roadmap to fix that now.

Anyone here recommend a tech stack that overlays nicely to Coda’s featureset? I’m thinking specifically of how the database is handled and relational and the formula language. With the Coda doc feature complete all of the logic is there so its just a matter of finding the best platform to port to.

3 Likes