Hacker Newsnew | past | comments | ask | show | jobs | submit | kbanman's commentslogin

Ema | Software Engineer | Vancouver, BC | Hybrid (3 days/wk) | Full-time

Ema is building the Universal AI Employee — AI that handles repetitive enterprise tasks so people can focus on creative, high-impact work. Founded by ex-Google and Coinbase execs. $75M raised from Accel, Section 32, Prosus, KPMG, and others.

We're hiring software engineers to build the core platform: APIs, backend systems, data infrastructure, and front-end interfaces.

Stack: Go, Python, PostgreSQL, ClickHouse, Elasticsearch. Multi-tenant SaaS.

You'd be a great fit if you care about clean, test-driven code, have experience with enterprise integrations and auth, and thrive in a fast-moving startup where scope is broad and ambiguity is the norm.

Comp includes salary + equity + benefits, scaled to experience and level.

https://www.ema.ai/careers


Would love to hear about the same but in Canada - As far as I know we don't have any Hetzner-like providers here.


Love the product and you've nailed the simple design!

I'm concerned about email deliverability--Even more so after the email verification ended up in my spam. Handling incoming email is simple enough, but for this to be useful to my team we would want to be confident that the emails are ending up in the right place.


  Love the product and you've nailed the simple design!
Thanks for the kind words!

  I'm concerned about email deliverability
As I’m sure you can imagine, we’re very concerned about email deliverability. We use Postmark to send email and deliverability hasn’t been an issue thus far, but your verification email ending up in spam is not cool. I would ask some followup questions here, but troubleshooting this on HN isn’t ideal for either of us. Any chance you could drop us a line at https://letterbird.co/jelly if you’re willing to dig a bit deeper with us? Sorry for the less-than-stellar experience thus far!


I also liked the landing page.

Constructive criticism, might just be me: I would lose the phrase "jam on email"... something about it (too folksy?) rubbed me the wrong way.

Perhaps something simpler like "Say hello to Jelly, team email done right."


For a counterpoint - I like it! "Jam" reminds me of jam sessions and FigJam, both pleasant experiences.


Congrats on launching!

For anyone looking for more (open-source) alternatives, here's one I just discovered today: https://microsoft.github.io/kiota/


I've had success with NSwag for generating both TypeScript and C# clients. Highly customisable - maybe too customisable with the config being quite complex - there's CLI & GUI tools to generate configs though.

https://github.com/RicoSuter/NSwag

We use the C# client generator in our public sector project and package the results up within Nuget, works a treat.


Yeah Nswag is great, but pretty specific to the .NET ecosystem if i understand correctly ? Ideally we'd like this to become a universal generator where any dev/team/company publishing an API gets typed and idiomatic clients, including the long tail of languages.


It can work with any Swagger/OpenAPI spec AFAIK, does run on .NET though. Other than running it if you're just generating a TS client you don't need to be part of the .NET ecosystem at all.

But I like your idea of the universal generator. NSwag isn't the most friendly of things to configure & regenerate so something like your lovely site will make it easier for people. Best of luck with the project!


The article doesn't dive into why this group performed worse; to me that is of much more interest than the conclusion.

Just from my own observations I would expect that this is largely due to income differences in the two groups. Rich people are more likely to own iPhones and in my experience also more likely to be careless drivers.


I think iPhone users skewing younger is likely to be the culprit.


Hootsuite also started as an agency side project, and I'm sure there are more.

Intentionally following this model doesn't seem sensible though; with VC money so accessible if you have already put together a good team you might as well focus on the product itself. Agency work is not fun.


VC money takes time to get, it requires you to give up some part of ownership/control, and puts pressure on you to be a unicorn.

Fine for some; certainly not foolish to go a different route. Basecamp never wanted to be huge, just successful. I'm working on a project that our company funds through agency work, and it's fine.


Speaking as a former AWS Engineer, I disagree with the sentiment that they are able to glue AWS services together better than what a competing non-AWS company can do. Internally the use of AWS is subject to the same constraints and APIs you and I have.

Their competitive advantage is their captive customer base, which will much rather pay a premium to use an AWS-managed service than use another vendor.


AWS biggest advantage is in the enterprise space.

Which is that companies do not procure individual AWS services but rather AWS itself. Meaning that whenever AWS releases a new tool it is instantly approved and available for use across the company (baring internal processes e.g. security hardening).

Compare this with a startup which has to go through a 6 month long procurement process complete with vendor bake-offs in order to sell their similar tool.

If AWS continues to move into the application space they will surely dominate the enterprise because of this.


Our whole cloud procurement strategy is based on this page https://aws.amazon.com/compliance/services-in-scope/

Just yesterday I selected SNS for a project instead of a local provider because AWS put it through the security audits we care about and we don't win prizes for spending time on these decisions.


Yep, the two-step:

-- AWS advertises the tool via the console and preintegrates it from both directions

-- IT+Procurement already approved AWS for projects, so PMs can skip vendor/tool approval+onboarding dances and focus on the budget one

True of not just AWS but Azure + GCP too

Startups can compete, but gets into stuff like deep tech or cross-vendor integrations, where the visibility and integration advantages don't apply as much to the cloud vendors so they rather go after easier targets until they can't. (Folks here posted about UI, but for b2b, I disagree for most cases, unless there's something deeply technical about it that a 20 person team can't copy.)


The exception is open source software. Free Software's biggest risk to the org is patent and license encumbrance. If we can develop an easy way to detect such things in Free Software, and we develop communities where enterprises can freely contribute to them (to make them more Enterprsey), then it has a chance to replace incumbent managed solutions.


I'm mixed here --

- Historically, OSS seems to be free product dev for big cloud (... cue AWS's paid PR people to say otherwise ... ). Their integration, advertising, and procurement advantages makes it MUCH easier to win contracts before the OSS devs may even know it is being used and without a bid process. For a fraction of the effort and contribution, they are switching it to a model of monopoly channel owners vs content producers and and driving the sw margins to 0 on the content side. That's why anti-big-cloud LGPL-when-SaaS style licenses are emerging. There are always exceptions, but it's not the axis to compete on unless you do such a license..

- I agree about the community aspect, indirectly. If the software, in addition to being OSS, relies somehow on community and its steward -- not just source code -- and participation in it is somehow what's paying for the OSS dev, yes. For example, maybe the community is also a social network (Slack/Teams across orgs), or generating threat intel -- the software (post-scale) matters less post-scale, so forking is ok.


The ability to stop by the desk of S3 team member and ask whatever technical questions and get authoritative answers is enough to defeat any competitors who want to build products on top of S3.

Note mentioning accessing to road-map, strategic investment, genuine appreciation of product strength and weakness etc.


Don't forget being able to get high priority in the backlog if you need a feature from another service in order to launch.

Former AWS engineer who launched a service here. That, access to source code and being able to setup an hour-long meeting with any engineer are the big points. Not that I think that lacking these is insurmountable, but they're very nice to have.


You underestimate how hard it is in large companies to actually speak to the people in charge that can help you concerning your problem.


I did not, I am comparing that to a random guy from some random startup, who is ranking even behind the poor customers who cannot get hold any devs for their confusing issues of using AWS...


> Internally the use of AWS is subject to the same constraints and APIs you and I have.

Is that true though? IAM isn’t open, and things like service accounts and service chaining (a can only access b through c) are also not.


I've seen this done for new projects, and it works really well. If your data access patterns are truly relational (varied lookup paths) then it is probably not the right tool, but many apps can be modeled in a way that DDB handles well.

Highly recommended viewing: https://www.youtube.com/watch?v=HaEPXoXVf2k this talk explains how relational data can be efficiently modeled for key-value stores.


Very well done!

I had started on a similar idea a while back, but never got around to it. Even have a cute domain for it (pifork.com) in case you're interested :)


Having been in your position, I understand that having built a product from the ground up makes you feel like you are qualified to do anything. I was lucky enough to get hired at a late-stage startup after my endeavor failed, and am constantly reminded that time in the industry matters. Two years of intense coding is worth a lot, but you've only been exposed to a limited set of problems, both technical and business. 6+ years sounds reasonable to me if they are looking for someone with well-rounded experience.

Mind you, as someone else mentioned, some folks spend 6 years in the industry and don't gain the knowledge and experience you already have, but that doesn't mean you've attained 6 years worth of knowledge and experience.


I don't claim to be as good as someone with six years of experience (I'm not delusional). Nor am I claiming that there are no companies that need to hire senior engineers. I'm well aware of many types of problems for which I am not qualified to solve. What I am asking is, does EVERY company need to exclusively hire senior engineers? I've interviewed at companies whose product was not much more than a CRUD app, and, despite performing fairly well in a technical assessment, was rejected for lack of experience (even though they could see how much experience I had right on my resume).

Most companies don't need the best of the best of the best. They can save a lot of time and money by hiring someone who, with just a little bit of investigation, they know is going to come in with some decent technical skills, and can quickly learn to become a valuable asset.


Companies with that mindset invest heavily in interns: you get a three-month work sample in your working environment & can (initially) offer them less than an experienced engineer.

Most companies have problems they needs solving right now or in the near future, not when an intern gets experienced enough to tackle it.

> come in with some decent technical skills, and can quickly learn to become a valuable asset

This sounds like you described a consultant.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: