Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: FlyCode (YC S22) – Let product teams edit web apps without coding
141 points by JakeVacovec on Sept 6, 2022 | hide | past | favorite | 50 comments
Hi HN community, we are Jake, Tzachi and Etai, co-founders of FlyCode (https://www.flycode.com/). FlyCode makes it easy for product, UX, and marketing teams to edit web apps without coding, so they don’t have to wait on (or consume) developer time, and can iterate, test, and release faster. See a quick example here: https://www.youtube.com/watch?v=jDL5oa2nEHo.

Non-technical teams frequently need to edit the copy (text), images, and links that appear in a web app. How to manage these has long been a pain on software projects. You can keep them separate from the code, in some form that non-programmers can edit, but this adds a lot of complexity and is usually brittle, as it can bypass the regular development workflows (CI, staging envs, deploy previews). It’s simpler to keep them in the code, but then only programmers can easily edit them. Everyone else has to wait to get their changes in, plus the devs have to do a lot of edits that aren’t their main work. This slows projects down and is expensive. It also means that product/marketing/UX teams can’t do things that require rapid iteration, such as sophisticated forms of A/B or usability testing. This limits their work and ultimately is bad for both quality and revenue.

There have been many approaches to solving this dilemma, including custom built admin tools that are limited in functionality and require maintenance, offloading to CMS that require heavy integration, are normally used for simple static apps, and bind your stack to their SDKs. Or wasting a developer’s time to do it for you…

We took a new approach by automatically analyzing a codebase’s structure, similar to a compiler. This allows us to automatically prepare a project-specific version of our platform which product/UX/marketing teams can easily use to edit their text and images. We programmatically turn those edits into code changes. Our GitHub bot then takes these code changes and creates a pull request just like a developer would—but without the latency (and boredom!). Developers retain codebase ownership, while non-developers become individual contributors to the dev process, just like others.

We use well-established practices for parsing and editing source code (like https://github.com/facebook/jscodeshift), covering most of the major technologies used for building web apps (React, Angular, Vue, and Ruby on Rails included).

Once our software has parsed your codebase, it generates an editing portal for your app that teams can easily use to find, manage, and edit product copy, images, and links, and then auto-generate PRs. You can edit product copy regardless of whether it is in resource files or hardcoded (fun fact: some of the largest and fastest-growing tech companies have most of their strings hardcoded!), and you can replace and upload new images and icons to your product.

The integration with GitHub (https://www.flycode.com/developers) took us a long time to get right. There’s not a lot of documentation around integrating GitHub to platforms, and things like connecting an org or connection requests turned out to be non-trivial. We're proud of the result because unlike with other tools, you don’t have to do any significant integration work.

Our GitHub app finds texts and images in the source code and sends them to our platform (you have full control of what and where we scan). Once a user requests a change it updates the texts and the images in the codebase and creates a pull request.

We did a Show HN earlier this year: https://news.ycombinator.com/item?id=31166924, which helped us get some serious leads, which was awesome. Since then we’ve moved out of beta, added new content types (images!), launched a new UI and visual editor (EAP), and automated the onboarding of new repos.

We have a handful of companies paying for this and spent the last year focusing on making it extremely simple to use. It only takes 3 minutes to connect our GitHub app and configure the system for your team to start editing. It doesn’t require any changes to your code, or any special maintenance. You can get started here: https://app.flycode.com

We are hoping to use this launch to get some more feedback from you all! We are far from our vision to be a platform for everything front-end but are working hard every day to improve the user experience and feature requests from our early collaborators (editing links, themes, variables, JSON configuration, defining in-code A/B tests, etc.).

We're really happy to show this to you all and thank you for reading about it. For those that sign up, time yourself to check that our “3-minute connect + config” claim isn't just a sales tactic! We look forward to further conversation in the comments.




I can't say I fully understand this from start to end but I like the idea.

At my current employer the main site is just a marketing site and our approach from the folks who write code is "You guys edit that however, leave us out of it.". We gave them some tools / training to do so. Side effect is those guys just do their thing with what they have and don't bother us about dorking with the marketing site for endless silly reasons, back and forth and so on.

If we were bigger / had a lot of other UI change requests, I think something like this would be very interesting to mitigate all the text / UI churn.


Definitely! FlyCode is best suited for web apps, which unlike marketing sites must be written in code and most often code that is not accessible to the rest of the organization.


Why not include a demo org and/or demo public GH repo that can quickly be tried out? I wouldn't want to grant GH access to every service I try out. Just thinking aloud.


That's great feedback! Once you sign up you can fork one of the example repositories and grant the system only to it. We're also exploring other options to show the product's value but to really feel it the GH connection is required.


I built something related to this for our webapp. Most of the text in the app is in a language specific "key to text" map that is loaded at runtime. I made a bookmarklet that switched the language into a debug mode where the keys mapped to a "<file>:<language-variants>:<Key>". You could switch to this "mode" with a simple keypress. User then highlighted the key they wanted to change, pressed another key-combo and was presented with the different translations and could change them (and switch back to normal mode for a preview). Lastly they could generate a PR with the changes they wanted and a Dev could make sure the strings worked (e.g. validating they had not removed a needed placeholder etc). All in all pretty nifty tool.


That sounds like a really cool solution! People come up with all kinds of clever workarounds for this problem but then get stuck maintaining and scaling them. This is one of the things that inspired me to join FlyCode solving this once and for all instead of ad-hoc.


Am super interested in the visual editor. It seems a very difficult problem to solve. Are there any examples (screenshots?) you could share?


Yes! You can checkout the solution page in our website (especially the video): https://www.flycode.com/product/solutions/chrome

It's currently available as part of an early access program that you're welcome to join :) You can contact us via the chat in the platform, or email hello[at]flycode.com


If anything, this is a marketing trojan horse. I think we should do more pushing back and less trying to idolize this behaviour. There was a time where developers made things for themselves or other people, not just marketers. As a developer, I don’t think marketers add value or better workflows. Generally, marketers are driven by intangible goals that rarely produce positive results. I’ll take my deserved downvotes.

The popularity of this just means your marketing bosses will use it to ram this concept down your throat. One of the saving graces against marketers is them not having this sort of direct line to customers. That gate is an important one.

I’m just giving you my experience. You don’t have to like it.


I kind of see your point, but to me FlyCode does not look like a product that will push further this "evil marketers' will" that you speak of.

It will allow product owner and his product team to make instant changes to their product, save precious developer time and reduce the amount of people required in the loop. All this product brings is benefit of saved time and resources.

It does not propel the marketers' feel of power. I keep thinking this tool will help the non-technical app owners to instantly make necessary changes without having to pay for this service and wait few days.


I do think FlyCode will be most impactful at companies with the least effective marketing arms. Liberating Engineering/Product from time-consuming marketing maintenance means they're free to work on problems that might otherwise be back-burnered. It also places accountability for marketing results more cleanly in marketing's hands.

If a marketing team is so incompetent they manage to tank the company by changing copy and images, well, that's a deeper problem and they should be fired, not babysat.


> well, that's a deeper problem and they should be fired, not babysat.

How that mentality works out in the real world: https://en.wikipedia.org/wiki/Cambridge_Analytica


Founding Engineer here. We are passionate about the use case for R&D as well as marketing. We see Product Managers, UX Designers and UX copy editors editing copy and images through the platform.


This is cool. Ignore the people, like the above, who are scared of change and teamwork. Keep building!


Hey, please don't take my comment as an attack. It's a lot of hard work, but I have to give my perspective - which also involves a lot of hard work in that I have been pushing marketers back for years, for everything from unnecessary personal information capture to portraying negative images of young women. Unleashed, marketers don't do well for us or the world.


We're happy to field any questions or opinions without judgement :) if one person shares theirs we assume others may think similar... that's why we love HN


interesting perspective. but i doubt this is a tech problem. instead, it is highly likely an organizational problem. FlyCode is a technology that reduce friction, but it is up to how you use it.


Congrats on the launch.

I’m curious about a few things

Isn’t it better to have a distinct ‘playground’ for marketers, PMs, UX/UI (separate from what Dev is working on)?

Shouldn’t PM/Marketers be dealing with very minimal stuff (like mock-ups, Visio Diagrams)? My immediate thought is that having these folks spend considerable time on (what you have described) almost seems like a waste of man-hours because at the end of the day, what Dev builds for code will be way better and efficient.

Finally, how do you plan to compete with tools like Figma and others which are positioned to allow the people you’re targeting create quick mock-ups (personally, I think those Apps are also not that easy to use)


Great note here - We see your point and need for playgrounds, we consider our solution complimenting Figma and other mock-up tools.

We'd like that other stakeholders in the company to actually be able to contribute to the codebase and make actual product edits, as well as creating mock-ups.


How does this compare to https://www.plasmic.app/ ?

It seems to have a similar goal of allowing product and marketing teams to update web pages with little to no code.


As you said: both products have a similar goal but Plasmic and FlyCode's approaches are pretty different. Plasmic requires using their own libraries in the code for making it editable and focuses on editing content that is in CMSs such as Contentful. FlyCode requires no such integration. It reads the existing code and allows users to edit copy inside the code without any action required by the developer. This is the reasoning behind our claim for "3 minutes setup". For developers FlyCode is "transparent": it doesn't affect the code and can be removed at any time. Also, from their examples it seems like Plasmic focus on content / e-commerce use cases while FlyCode focuses on web-apps (e.g. B2B SaaS).


I largely agree with your take!

But just to clarify one point: Plasmic (importantly) doesn't require using any specific libraries. You can bring your own arbitrary React code.


I work on Plasmic. I think we're quite different! I would summarize as:

- FlyCode focuses on text/image changes within your existing code.

- Plasmic lets you create and edit UIs using your React components as building blocks, but doesn't try to edit your existing code.

For making text/copy changes, there's also another product that uses your Figma designs as a source of truth:

https://news.ycombinator.com/item?id=27142930


Appreciate the summary! There are a handful of new players building around react components - really interesting space. We believe this is one aspect of a broader movement so educating the market is a group effort :)


Hey, thanks for the feedback. Yea sounds similar goal but different: (1) no integration with us (no API just Git connection) (2) we keep your code ownership - continue to edit from your code, no need to change your infra (3) we are not a CMS -> we connect and extract from the code directly so the capabilities are different

Last thing - git work flow. Your code -> you are approving the same way you work today


Congrats on launching! I work on Plasmic. I have a sibling post on how I think we're quite different. But just to also clarify some points:

(1) Plasmic does support git as well.

(2) You can also continue to edit your code.

(3) You can use Plasmic as a CMS, or as a code generator.


Nice alternative for a CMS or Webflow for simple use cases.

Nitpick: “developers time” -> “developers’ time”


100% correct, we'll go hide in the corner for a bit haha.

Next thing we develop would be a HN post editor XD


Congrats on the launch! This is an awesome concept, I don't think I've been on a single team that wouldn't have benefitted from having a tool like this.


You mentioned AB tests — how do you see FlyCode allowing the product team to run AB tests without developers specifically adding AB test support?

I wouldn't mind if devs only needed to make a one-time change and then product could run AB tests on any page they wish.


We're strong believers in a BYOI(infra) model where FlyCode works within your stack and tooling instead of making you change to support us. With that we are exploring integrations with experimentation platforms like Split.io, Amplitude and others to enable product teams to add/modify variants, select cohorts, etc. directly from FlyCode's interface. We then make adjustments in the code w/o involving dev.


Is GitLab on the roadmap? (Not expecting, just hoping!)

Thanks!


This looks awesome! Clever idea, seems like it solves a real problem. Nice job y'all.


That seems a relay interesting product in order to "free" developer of minor change without removing the production control thanks to PR but I have some concerns about:

- The fact that the organization has to open their GitHub to your infra

- The fact that by reading iddan message: "We see Product Managers, UX Designers and UX copy editors editing copy and images through the platform." it seems that you have access to client data in read at least

For all of those concerns do you offer an on-prem version of the solution for organizations that can't on don't want to deal with that?

Thanks it looks like a very interesting product


Great comment but just before I get into it I'd like to clarify: we have no access to your clients' data. We are just starting out and we'll definitely consider special solutions for special needs but for the majority of the organizations giving access to frontend code is not a security issue. Especially for a credible company that complies with security standards (see startups like Netlify and Vercel).


I like this - in fact, I could've used this in my last company.

How do you deal with resource files for multi-language apps?


Great question, there are lots of multi lingual apps out there, and although localization isn't our main use case - We support multi lingual apps by identifying the resource files that contain the key-value pairs. From this point our platform continues to work as usual.


This would have definitely saved the product team at my previous workplace from a lot of pain.

Mazal Tov for your launch!


That's what we're here for - thank you for the support. If they're still in need we'd love to support.


Any plan that requires predicting the future is a poor plan. Which choice is optimum is unknowable, so screw trying to pick the perfect option and do what you want to do. Do you prefer staying free of the VCs? Or like the idea of joining their team?


What about screenshot tests in the ci pipeline? Who updates those?

Is there a constant somewhere I can import in my unit tests so I can say “expect this header has no embedded js but says whatever Dave from Marketing wants”


Great question! It's definitely a use case we are thinking about. Anything from giving a better framework to this to updating the screenshot tests for you are viable options. About importing the copy to unit tests: it depends on your setup: for projects that have hardcoded copy, we update the copy inside the code, for projects that use I18N we update the I18N JSON/PO files.


What happens when they copy/paste from Word Doc a thousand <!-- StartFragment --> and other random BS Word injects?

Do you limit their changes to just plain text? Then they ask "Why doesn't the website look like the Word Doc I made? It looks perfect in Word!" Where is your God then?


You unit test header text content?


I mean it’s a webpage with html. I would like to know it’s producing the right html.

Not necessarily the content, but that the correct content is where you want it.


The webpage is not fully loaded, I see error in the console:

    None of the “sha256” hashes in the integrity attribute match the content of the subresource.
    Uncaught TypeError: s is not a function
    Uncaught ReferenceError: $ is not defined
It seems failed to load jquery from CDN.


Congrats on the launch.

How does this differ from competitors in this space, e.g. let's say, TinaCMS?


TinaCMS is great :) We differ from them and others in this space by taking the approach of making changes to code that the dev team manages (rather than markup like MDX). The tools are solving separate use cases, the one is managing content (which can be interactive but is mostly static), and the other is editing UX copy integral to the web app (which is usually inside react code for example)

We see a lot of opportunity in managing resource in git and are betting that the industry is going there, so shout out and love to the TinaCMS team and other players recognizing that git is where app resources should be managed.


This is super cool, and a great way to implement it - hard - but will make adoption much easier than if it had to be implemented, or installed, etc.


Pretty cool




Consider applying for YC's first-ever Fall batch! Applications are open till Aug 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: