jessouyang

Hey all-- I'm one of Ditto's cofounders. Grateful for all of the support when we Launched on HN a bit ago. Happy to answer any questions if anyone has any!

Just wanted to follow up on this and mention that we've just rolled out our localization features. Ditto now handles variants (including languages, user segment-based text, and more). I wrote about it here: https://www.dittowords.com/blog/introducing-variants-for-loc...

It's been in development/QA for a while, and we were super excited to see all the feedback and questions about localization during our launch.

Frankly we're flattered that our launch has gotten the attention of localization tools (hi localazy + lokalise, thanks for joining us on HN!). Always appreciate others working on solutions for product text in all of its stages.

Although we do think we play an integral part in the product development process, if teams switched off Ditto, they wouldn't be any worse-off than they were before. The text would still exist in their mockups, and their apps can continue to serve the structured JSONs of text that we generate. Because we aren't a CDN, they aren't dependent on us to actually serve that text.

However, we do hope to have an on-prem offering for enterprise customers in the future, especially those with tighter security constraints!

Thanks so much for the support -- we feel really lucky and excited to have been able to grow Ditto over the last year. :)

Right now, teams in Ditto use it as a translation/l10n solution if they already localize their mockups. However, we are hoping to support this more fully in the very near feature (likely this upcoming week!) with the ability to create variants of text in mockups in Ditto (including languages, user groups, states, etc.).

That means a lot, especially because we handle all of the design (including the landing page) in-house. Thanks for the support!

We're actually launching a feature called Variants to tackle this very use case (and translations) in our app in the next few days! It's definitely been highly requested by teams using Ditto and will hopefully allow them to create variations of text for different mediums, audience, user segments, etc.

Curious to hear what kinds of audiences/mediums of communication you typically account for in your product, and how much variation in the product text is written for each?

Hey Tejas, great to see you here on HN! Thanks for the support both then and now :)

Thank you for your support!

Definitely been there as an engineer as well. The amount of overhead and engineering time it takes to make punctuation changes, fix spelling errors, and even simple iterations to copy in-app only increases as a product's surface area increases. Thanks for forwarding us along!

Totally -- even beyond just spacing/fitting in content into the designs, the text in-app strongly informs what the user knows and understands, which is critical to the design itself. Designing with lorem ipsum and other placeholder text has a lot of potentially negative downstream effects, in addition to slowing down product development.

Wow, great catch with the Safari font issue; we've just fixed it. Thanks for finding that!

Thank you!

- We released first released our web-app and Figma plugin around a year ago, right at the end of our YC batch (Jo and I went into YC pre-product). Our developer integrations (API/CLI/SDK and Developer Mode) were released 2 months ago.

- All of our customers (including larger enterprises) have actually found us organically! We were lucky to have the support of different design and content/UX writing communities from the start, and they were able to champion the tool on their teams. We've tried our best to be super hands-on with these teams, offering onboarding and support calls, shared Slack channels, and tips on selling Ditto to other stakeholders in the company. On some teams, however, we're definitely still working to expand outwards from content to design to EPD, especially with our new developer integrations.

Thank you! That means a ton.

1. We integrated with Figma first on the design side due to a couple of reasons: we were really excited about the growth on the platform, the community, and their ability to serve as a single source of truth for design (with live editing). As an early developer on both their Plugins platform and REST API, we've definitely seen their APIs evolve.

Ideally, we want to be design-tool agnostic (including integrating with Sketch, AdobeXD, InVision, etc.) and integrate with everywhere copy lives (including docs, sheets, etc.) once we have enough engineering bandwidth. We think serving as that text layer / infrastructure for text is a fairly different value prop from design tooling, but we do hope to decrease our reliance on Figma over time.

2. Copy is definitely unique in that it's touched by so many roles horizontally in an org (not only in EPD but also marketing/legal/etc.), unlike a lot of role-based tooling (devtools, design tools, etc). We've been really lucky so far in seeing a lot of our growth happen organically by those at larger companies with roles owning the copy (UX writers, content designers, copywriters, etc.) championing our tool to other stakeholders. However, this is definitely something we're still trying to figure out how to do effectively, and we've seen some cases where adoption is held-up because of cross-team communication.

3. At the moment, Ditto brings text into development as structured JSONs, which we keep fairly open-ended on how teams want to integrate into their UIs and 3rd party tools. They can also manipulate the text in development and/or bring it into A/B testing frameworks. In the future, we hope to handle some of those use cases ourselves :)

1. At the moment, we've seen teams use Ditto to localize if they already localize their mockups (i.e. have mockups in different languages). However, we're releasing the ability to create variants of text (i.e. for translations, user states, etc.) not mocked up in the design in the upcoming week. It's been in development for a while (and to be honest we were hoping to release it before today), but still requires a bit more testing.

2. We built Ditto to specifically tackle product copy, whereas existing CMSs (including headless CMSs) are much more geared for marketing copy (longer form, clear H1/H2/body structure, authorship, etc.) -- which we think are pretty different use cases. With product copy and microcopy, teams have to think a lot more about how that fits into the UI/design/implementation; we're also excited about how our CLI can fit into teams' dev processes (like CI/CD) to streamline workflows!

3. Yup, we're super excited about all the potential extensions of Ditto, A/B testing included.

Thank you for the support! It is kind of crazy how much copy-pasting there is for every single role involved. We think a large part of it has to do with the fact that copy exists and is worked on horizontally in an org -- unlike more verticalized, role-based tools (devtools, design tools, etc).

That's great to hear! We've definitely seen an increasing amount of teams separate product copy out into JSONs ("decoupling copy and code"), and we hope Ditto can help them manage that.

We don't have a standard SLA on the API at the moment, but in the past, we've negotiated and signed SLAs for enterprise teams. Happy to do so for you as well if you want to shoot an email to founders@dittowords.com!

Many localization services / Translation Management Systems (TMS) (like those listed) or developer tools (Lokalize, Phrase, etc.) tack on l10n as a layer at the very end (after development). Especially with these 3rd party contractor tools, a lot of the time the l10n happens without context of the design / product -- they just translate the strings that exist in production.

At the moment, we've seen teams in Ditto use it as a localization solution if they already localize their mockups. However, we are hoping to support this more fully in the very near feature with the ability to create variants of text in mockups in Ditto (think languages, states, etc.)

Localization is definitely a pretty big pain point for teams, but we've seen teams struggle to coordinate copy from draft to design to development, even in their primary language.

Ditto (YC W20) | Backend + Full-stack Engineers | Onsite (SF) or Remote (US Only) | https://www.dittowords.com/careers

Ditto allows teams to manage their copy from design to production with a single source of truth. Over 2600+ teams (from Fortune 500 companies to startups!) currently use Ditto.

We're a team of 3 engineers looking to hire our 4th and 5th team members to help scale the product. We've recently released our developer integrations to sync copy from end-to-end, and some of our customers include Stripe, Zoom, Canva and larger enterprises.

We're offering foundering engineer equity, competitive pay, and health insurance. We're looking for empathetic & clear communicators with 3+ years software engineering experience. Bonus points if, like us, you're interested in the future of design tools and devtools!

To apply or if you have any questions, email founders@dittowords.com.

Stack: MERN (MongoDB, Express, React, Node.js)

Jess and Jo here, and we're excited to share Ditto with you all (https://dittowords.com). Ditto is a way to manage and componentize product text from design to development. Think of a headless CMS but with the text from your design files.

We think product copy, or the text found on user interfaces, is the most under-leveraged part of product development today. Even more so than the visuals, the text users read is critical to shaping their understanding of how things work. Copy often gets coupled as a part of design, but it's worked on so cross-functionally — from design to legal to marketing to engineering.

Jo and I have been on teams at both small startups and tech giants, and at every place we've seen product copy being written ad-hoc and scattered across mockups, docs, sheets, and tickets. The back and forth required just to fix a simple typo in production often included a backlogged ticket, several Slack conversations, and a ton of wasted engineering time better spent on building.

At its core, we wanted to build a way to treat product text as a system, with the ability to componentize text for reuse (just as we do for development or design!). We spent the last year building out and iterating on Ditto, deciding first to tackle how copy was managed between design files and content writers with our web-app and Figma integration. However, our intent from day one has been to build a single source of truth from end to end.

Initially, we took a stab at integrating into development by building a Github app that created pull requests for copy edits made in Ditto. This somewhat did the job (democratizing access to making text edits in development), but we saw users struggle with the maintenance it required and realized it was a piece-meal solution to a system-level problem.

Over the last few months, we built out an API (with a companion CLI and React SDK) so that Ditto could function similarly to a headless CMS and sync text from design all the way to production. The API/CLI fetches up-to-date product copy from Ditto into local directories as structured JSONs with unique IDs. As a locally hosted and updated JSON, you always own your copy, can see copy diffs on commits, and won't have to worry about latency (we're not a CDN).

Building tools for copy inherently means building tools to improve existing design and development workflows — and we'd love to hear what you think and how it can be improved. Jo and I are roommates (and have been since college!), and we'll be sitting next to each other answering comments.

To check it out (with a quick 3 min video of me talking through the features): https://www.dittowords.com/developers.

We also have instructions for setting up / playing around with a sandbox Figma file and React app here: https://developer.dittowords.com/getting-started/use-our-cli....