[HN Gopher] Launch HN: FlyCode (YC S22) - Let product teams edit...
___________________________________________________________________
Launch HN: FlyCode (YC S22) - Let product teams edit web apps
without coding
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.
Author : JakeVacovec
Score : 105 points
Date : 2022-09-06 13:28 UTC (9 hours ago)
| kierenj wrote:
| Am super interested in the visual editor. It seems a very
| difficult problem to solve. Are there any examples (screenshots?)
| you could share?
| etai-flycode wrote:
| 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
| a-bit-of-code wrote:
| 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.
| iddan wrote:
| 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.
| [deleted]
| shredprez wrote:
| 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.
| nocommandline wrote:
| 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)
| etai-flycode wrote:
| 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.
| robertlagrant wrote:
| 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?
| etai-flycode wrote:
| 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.
| mvd7793 wrote:
| This looks awesome! Clever idea, seems like it solves a real
| problem. Nice job y'all.
| gagangulyani wrote:
| faheem_khan1 wrote:
| talhof8 wrote:
| This would have definitely saved the product team at my previous
| workplace from a lot of pain.
|
| Mazal Tov for your launch!
| JakeVacovec wrote:
| That's what we're here for - thank you for the support. If
| they're still in need we'd love to support.
| devGreg wrote:
| 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
| iddan wrote:
| 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).
| jahewson wrote:
| Nice alternative for a CMS or Webflow for simple use cases.
|
| Nitpick: "developers time" -> "developers' time"
| etai-flycode wrote:
| 100% correct, we'll go hide in the corner for a bit haha.
|
| Next thing we develop would be a HN post editor XD
| zoover2020 wrote:
| Congrats on the launch.
|
| How does this differ from competitors in this space, e.g. let's
| say, TinaCMS?
| etai-flycode wrote:
| 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.
| duxup wrote:
| 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.
| iddan wrote:
| 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.
| tomlin wrote:
| 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.
| iddan wrote:
| 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.
| tomlin wrote:
| 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.
| JakeVacovec wrote:
| 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
| [deleted]
| mcphail wrote:
| This is cool. Ignore the people, like the above, who are
| scared of change and teamwork. Keep building!
| shredprez wrote:
| 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.
| tomlin wrote:
| > 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
| samyou wrote:
| 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.
| zaxanq wrote:
| 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.
| nkingsy wrote:
| 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"
| iddan wrote:
| 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.
| halfjoking wrote:
| 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?
| toqy wrote:
| You unit test header text content?
| nkingsy wrote:
| 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.
| archevel wrote:
| 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.
| iddan wrote:
| 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.
| arjvik wrote:
| 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.
| JakeVacovec wrote:
| 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.
| [deleted]
| azhenley wrote:
| 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.
| iddan wrote:
| 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).
| xyzzyrz wrote:
| 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.
| xyzzyrz wrote:
| 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
| JakeVacovec wrote:
| 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 :)
| peekypeeky008 wrote:
| 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
| xyzzyrz wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-06 23:00 UTC)