matijash

No worries, appreciate it, but I didn't feel attacked! Also learned a new word (corpspeak) :)

Thanks! Haha yes, it definitely felt like it at times. Fundraising really took me out of the product pretty much completely, so my co-founder was keeping the fort there and keeping us afloat. At first we were fundraising together, but then we quickly realised it just wasn't feasible.

The next thing was hiring - in many ways similar to fundraising, a lot of lead generation, rejections and also very occupying.

I think and hope now will be a bit easier to get back to the product, but there are definitely things that from time to time completely consume you it seems.

Funnily enough, but it actually didn't feel that way at all. Investors definitely communicate and share their dealflow a lot (a lot of vcs told us they heard about us from others and wanted to meet us, although we mostly had no's.), but my impression is they are not discouraged by no's from others, if they like what you are doing.

I assume that is because they understand there a lot of different reasons behind no's (bad timing, wrong stage, not excited about the area, ...) so it doesn't automatically mean something is fundamentally wrong with the company.

On the other hand, getting yes is definitely a big signal for others and makes them move much faster.

To me it all felt like a really fast game with a huge pile of deals on the table where everybody is just digging through and looking for something they like - no is here just a default answer and everybody has their own "filters" and premises they are going after.

This is why it really helped us when we focused really narrowly on finding investors who are a good fit for us, that was probably the biggest factor of all.

yeah, definitely. The advice we often got was to either go fundraising full-on or not at all, because it's very hard without that momentum that takes time to build up (as you could see on our chart, in the end we had even more interest that we aimed for, but took time to get there).

I never did fundraising pre-Zoom/covid so can't compare, but the advantage here was the sheer volume of meetings we could do in a single day. I guess that in-person it would be easier to build rapport, but Zoom was definitely an advantage when playing the numbers game.

this is helpful, thank you!

At that time we were pretty much fundraising full-time, and given there were only 2 of us and the product was at early stage we couldn't really do a meaningful push on traction, so we mostly focused on the updates on the fundraising side.

The basic format of the follow-up was "Hey, you mentioned you'd follow-up in X days so I wanted to check if you are still interested in investing?". Then I would, if applicable, also add a line like e.g. "since we last spoke, we raised another $X from investor Y" or "we almost closed the part of the round dedicated to the angels and have only $X available".

I would send over a SAFE only if the investor agreed to invest and had completed the handshake protocol (https://www.ycombinator.com/handshake/).

yeah, "Fundraising lessons learned post-YC" prob would have been better, thanks.

I am not a native speaker, so this definitely might not even be a proper word :). Some discussion about it here: https://english.stackexchange.com/questions/396140/is-there-...

thanks a lot for the info!

sorry about that, seems like HN is doing some URL expanding which messes it up, this was the original URL: https://wasp-lang.dev/blog/2021/11/22/fundraising-learnings

We are building a DSL for building full-stack web apps (in Alpha rn) - https://wasp-lang.dev/. It is designed to be stack agnostic, but currently we support React & Node.js.

This is a great summary of the problem, upvoted.

I like the "peeling off" strategy - starting with the monolith and adding microservices from the edges.

I've been working on something that tries to make starting with a monolith in React/Node.js relatively easy. Still don't have much of the "peeling" support but that is something we're looking to add: https://github.com/wasp-lang/wasp

thanks for the twin love, love the question! :)

haha yes, we are not identical (although similar at first look) so no huge (fun) misunderstandings, but we have similar names and same initials so that caused confusion several times. Whenever I got more points on the exam Martin would suspect they mixed us up and go check :D.

Otherwise it is really rewarding to work with a brother! We can agree really quickly and can skip all the formalities and pleasantries when making decisions since we know each other so well. Would definitely recommend :)

just wanted to say I love the idea! Would definitely use it if it was available in Croatia :)

Btw, how are you solving routing right now, any cool algorithms? :)

oh wow, that's really great to hear! Would love to get more of your feedback once you tried it - feel free to join our Discord channel (https://discord.com/invite/rzdnErX) or email me directly at matija@wasp-lang.dev if you'll have any questions

thanks for sharing, definitely sounds like an interesting combo! How is your experience with Hasura/Firebase, anything you found cumbersome?

Get it now! The big part in our opinion is growing a community of people using Wasp for their projects - if we manage to do that, we'll definitely be motivated to continue, funding or no funding. We are of course motivated to build a business on top of Wasp, but for now still focusing on the product.

Thanks for the info about licenses, awesome overview!

would be awesome to chat!

thanks for your feedback and questions! yes, it (build-time reasoning) is also the most exciting thing for us, really excited to see what can be done.

I also totally agree on being harder to debug, that is the challenge that comes with abstraction - at this stage we are not doing very much about it (mostly just propagating errors from server/client) but it is something we'll definitely need to focus on as Wasp matures.

We chose Haskell because we had some previous experience with it and thought it would be a good fit for building a compiler (doesn't have a lot of realtime IO so we can keep the code simpler). Haven't yet tried OCaml or Rust (heard Rust is somewhat more low-lvl) but I believe they would be viable alternatives too.

Re long-term doing Wasp - also agree, we believe this is a full-time job so that is why we joined YC and got the initial funding so we can focus on it longer term.

Re Apache v2 vs MIT - thanks for letting us know! We haven't yet put much investigation into it but will definitely need to do it soon.

we are not totally sure yet (since we are now focusing on getting the project to the stable stage), but we think the most straightforward way would be to provide our own, "one-click" deployment/hosting service. On the other hand, since we are providing an e2e solution we think there could be multiple spots for providing extra value on top of the language, but we have yet to explore it.

thanks for the feedback, I agree having showcases is crucial for showing what can actually be built with Wasp.

We ourselves built a copy of Medium with Wasp - feel free to see it deployed here (https://wasp-rwa.netlify.app/) and check the code here (https://github.com/wasp-lang/wasp/tree/master/examples/realw...)

For the super simple example with less code check out TODO app built with Wasp: https://github.com/wasp-lang/wasp/tree/master/examples/tutor... (check out main.wasp and then the code in ext/ folder)

Hope this helps!

we also have a DSL design channel in our Discord - feel free to join and start the discussion, we'd be happy to learn from you and also help if we can! https://discord.com/invite/rzdnErX

thank you, that is what drove us too! But we also believe the key is in keeping integrations with the existing tech, e.g. React/Node.js so it is still possible to express more custom logic where it is needed.

hah that would be cool! One reason we are excited about the DSL approach is that it allows us to 'capture' web app's requirements in a declarative structure separated from the implementation.

As you mentioned, that means it could be possible to generate Wasp DSL via other means as well, not just by writing it down directly (e.g. via a visual editor), and some specific parts could be even assisted by AI.

right now Wasp DSL is pretty much the config file, it isn't much more expressive. Short term benefit is that this way we can provide nicer & more intuitive syntax (config files like json/yaml can quickly become very nested and hard to read).

Longer term, we plan to add support for inline-JS, so you could e.g. mix JS and Wasp code (instead of just referencing js imports as it works now). We will also add some basic language constructs (expressions, conditionals, multiple wasp files) so we might get more similar to e.g. Starlark or Terraform's DSL.

thank you, fixed! The correct link is https://wasp-lang.dev/docs/

Of course we will have unit (and other) testing support! But we are still in Alpha so didn't get to it yet :) Here is an issue on Github that tracks this feature, feel free too add your thoughts as well: https://github.com/wasp-lang/wasp/issues/110

Thanks for your feedback!

Yes! We are right now working on developing RealWorld app with Wasp, you can check it out here: https://github.com/wasp-lang/wasp/tree/master/examples/realw...

Webpage: https://wasp-lang.dev

Discord: https://discord.com/invite/rzdnErX

Docs: https://wasp-lang.dev/docs/

Todo App tutorial: https://wasp-lang.dev/docs/tutorials/todo-app

Github repo: https://github.com/wasp-lang/wasp