Comment by keithwhor | Hacker News Reader

Comment by keithwhor | Hacker News Reader

Hey all,

Keith here, founder and CEO of Standard Library (we made this <3). The problem we're focused on solving is simply -- building modern integration software is too difficult. (1) For professional engineers, it's mundane work nobody wants to do and (2) for non-developers, best-in-class integration tools that rely on visual workflows just don't cut sophisticated use cases for modern businesses, they often need some code.

Autocode solves these problems by providing an IDE that professional engineers can use to ship simple integrations in minutes and new (or "low code") devs can use to automatically generate API integration code without needing to know much to start with. We provide a ton of features: an API registry, API autocomplete, code generation, serverless hosting for your APIs, an in-browser execution engine for your workflows, observability + logging, complete revision history. It's kinda like Heroku and Zapier had a really, really ambitious child.

We've been at this, somewhat quietly, for four years and Autocode is what we're the most proud of to date. We've been very fortunate to have the opportunity to work with some of the best companies in the industry to support our vision -- Slack and Stripe have been investors since (nearly) day one. That said, we're a small team -- just five people -- and we still have a hell of a lot of work ahead of us. We would love thoughts and feedback!

YouTube video here for anybody that wants to see the full demo:

https://www.youtube.com/watch?v=ha3C0X3Vyi0

Thanks so much! :)

Very cool stuff, so I want to give some feedback hoping it will succeed :)

1 - Some playground prior to signup, similar to Runkit could get you more users.

2 - Some simpler signup by Github etc. would get you more users.

3 - Right click is taken over by the site, which blocks LastPass context menu which adds another layer of difficulty to signup.

Good luck, thanks

Thank you!

Ooh! Right click / context menu. I gotta fix that. D'oh.

I think there are different schools of thought re: providing a playground. We certainly have done that before with smaller launches. Our experience (anecdotally, I haven't measured exactly) is that while "playground" type experiences can sometimes increase signup volume, they tend to result in lower engagement rates overall.

I believe the basic underlying hypothesis is that if you can solve a problem somebody is having and they know that, they don't care how it works: they'll sign up and figure it out. However, if you provide a playground, you artificially select for a much higher proportion of folks who enjoy the novelty of new technology / products and aren't necessarily likely to stick around.

Food for thought, anyway. Don't have raw numbers here.

Yes and no.

This particular product probably has broader appeal than you think—

For a broader audience you'd definitely want to dumb down the entry point. If you're still in the smaller audience/specific traction stage, it probably makes sense to stay more technical.

UX feedback: Might I suggest that you zoom/crop for the last 2 animations on your front page? They are basically unreadable on a phone.

I'm also having trouble grokking what "build your own connector apis" is supposed to mean. I'm assuming you have more detailed docs/posts explaining your value pitch here, but I don't see any links to them on the page. Are you providing a nice wrapper over oauth/saml sso handshakes? Are you just opening a raw json pipe? I truly have no idea.

We allow you to write your own APIs using serverless functions to define the endpoints. If you choose to implement a raw JSON pipe, you’re free to do so — the flexibility is unlimited!

Thanks, we’ll look into communicating this more clearly. :)

Really cool product and a well-done demo. I noticed that the autocomplete didn't work for the co2 service (e.g. host says "I think it's response.ppm" rather than ppm being suggested. This despite the co2 service (presumably) being developed and published with autocode as well. The pervasive auto-complete and composability make the offering really compelling, but it's unfortunate that (at least in that example) the two don't work together.

On a related note it would be lovely to use (or allow) typescript and publish TS declaration files and thin generated clients for APIs deployed on autocode.

These are both minor nits in an otherwise impressive offering. Both are likely "next iteration" features since it seems like you've already solved a lot of the hard problems and these would be connecting existing dots together.

Thank you. It means a lot.

The reason `result.ppm` didn't autocomplete was because I didn't specify a return schema when I built the service. It's up to the developer who builds the API to specify nested object schemas via the FunctionScript specification [0] and I hadn't. It was a long day and I didn't feel like re-recording the entire video. :) Long way of saying -- it'll work if you want it to.

TS could be neat, it's conceptually not difficult, the question of implementation is ultimately: where does our team's time go as we continue to roll out features for business users? About half of our users are not professional developers so balancing between pro / not-pro is part of what makes our roadmap planning interesting.

[0] https://github.com/FunctionScript/FunctionScript

Would that be challenging to keep the wrapper up to date with wide range of API endpoints?

Reply on news.ycombinator.com