Hacker News Reader

Comment by swsieber | Hacker News Reader

I'm about halfway to launching a side project (I seem to be close than 50%, but there's always the 90-10 rule).

It's been fun. I've been writing the backend in rust, using squire for storage, and actix-web for the server framework. The front end is plain html without a lick of js. And my css is really just compiled scss.

I'm happy to report I've only engaged in a small bit of yak-shaving (writing a custom derive for defining APIs I need to hi from my backend for integration purposes) and only a small bit of framework churn (I switched web server frameworks because I wanted an abstraction that wasn't ergonomic/available in the initial one i had chosen).

And it's been fun. The best part is that even if it flops, my wife and I will still use it.

Edit: I've only been at it for a couple months

View on HN

Couple of months and you’re half way? So if you cut some scope you can launch by dec 31st right?

I have no idea what you’re working on but I bet you don’t launch till March at least.

I have already cut features - I was going to launch with multiple integrations, but I decided to just do one. The difficulty is carving out time, and being painfully aware that anything I go to do could give me a grief and cost me lots of time trying to figure it out :)

I am mostly done with the bare minimum of what I need for it to be usable for myself. I have a little more work to do. Not much though, I've tested the most of the bits I still need to do. Now I just need take that learning and finish building it.

I think I'm only halfway because I need to get billing working (planning on integrating with Stripe - there goes my no JS goal...), fix the CSS so it doesn't look terrible (doesn't need to be fancy, just passable), and work on my error logging / reporting. So... mostly polish. But not feature polish, but "don't drive away potential users via stupid stuff" polish.

Edit: I do hope to launch by Jan. 1 since new years resolutions could be a great driving force for new user signups, but your assessment is a reasonable guess.

I've heard of quite a few products that launched without billing in place yet.

They gave users a 30 day trial period, so starting on launch day, they had precisely 30 days to get billing sorted out if they hoped to be able to charge anyone.

A free trial period may or may not be suitable for your product. But you can probably get by without it on launch day.

You could even launch in beta mode and give people access in exchange for feedback.

If you're targeting graphic designers, then go ahead and tweak that CSS. Otherwise, go ahead and get some real people using it. If they're using it to solve a pain point, they'll quickly tell you what's good and what's not. And if they don't use it at all...well, that's valuable feedback too.

Agree with this regarding billing. I just made the mistake of spending a ton of money on getting this working and mind you I don't have any customers. Stupid stupid stupid.

Thank you for the advice. I hadn't considered launching without billing. I don't think a free trial for my product could be very long (since it involves sending lots of SMS which would cost me quite a bit if I get a big user spike). But I think I can provide a sort of demo without that bit.

Right, that makes sense. It's not the right fit for every business idea.

If you could find yourself a 5-10 beta customers, perhaps launching to them before billing is ready might work? You could even perhaps set a cap on how many SMS messages they can send per day or week. That would keep your costs low while still getting you some feedback.

You should of course do whatever is best for your product. I've just learned from experience that launching as soon as you can is great, because you'll often find that many of your assumptions about how and why people will use your product don't match how they actually use it.

I agree. Getting billing to work isn't the most important part. Get users first. If you don't have anybody using your stuff, having a store won't do any good. Once users complain that they can't pay you, you know you're on the right track.

You can always invoice them manually as long as you keep track of whatever your billable items are. If its SMS's then keep track of how many they've sent and there you go. As long as they pay that is, otherwise you are out of pocket.

What are you working on? I'm interested in Rust projects, especially web ones.

Integrating SMS (Twilio/Plivo) with Google Spreadsheets for Budgeting purposes. Basically allows people with custom budgets to get an easier form of transaction recording.

I had been using warp, but I wanted to write a custom middleware for some session / cookie management, but ran into trouble, so I moved to actix-web.

The google api crates also didn't seem to compile/work right for me, so that's why I wrote a custom derive. Basically, it allows you to define a struct that represents an endpoint, and you can just mark what get's included in the query, body, or in the url with some nice interpolation. And then I defined a endpoint processor that can take that and execute it, deserializing it. I implemented that for the reqwest client and for one of my custom structs, a google api token.

Here's an example of what a marked up struct looks like: https://gist.github.com/samsieber/d2efec774320c0af01ee72cb09... . It's a little rough around the edges, but I think by the time I'm done it'll have acquired enough polish to release it on crates.io - it's been super useful to eliminate a lot of the fiddliness I had been doing with making requests.

Reply on news.ycombinator.com