I always thought of serverless as yet another fad to come and go. In my career it seems like these things come in waves.
1. The single page application wave came and we rewrote our Rails 3 app to Angular.
2. Serverless came along and we were building things with Firebase and other services we didn't control.
3. Chat bots came along and suddenly we had automatic pop ups on our site offering help and sales.
4. Microservices came along so we broke Rails into a bunch of services and languages and frameworks.
5. React came along and we replaced Angular.
None of these things ever last. I focus on the fundamentals and keep my core competency strong. Learn old/boring/proven technology. If it has been around for 15 years it will probably be around in 15 years...
When my daughter was three years old and diagnosed with cancer (stage 4). To say it was "life changing" would be an understatement. It fundamentally changed who I am in a way I can't really express. It changed me in many positive ways and negative ways. With regards to my life, I can distinctly draw a line between "pre-diagnosis" and "post-diagnosis".
A second life changing event happened a few years after her diagnosis when I read "Meditations" by Marcus Aurelius. I think the book hit me at the right time and place in my life and helped me really process things that I couldn't before.
Any advice I can offer are things that seemed to work for me. I got "lucky" and struck gold on my first idea/project (consistently making high six figures over seven years running). I have tried other projects but none were nearly as successful.
1) Find your competitive advantage. I happened to work in a niche industry and learned it inside and out. I became somewhat of a "domain expert". I used that to my advantage and built my product to serve that niche. What can you do better than most people? What do you know inside and out?
2) Serve businesses, not people. People will do anything to not pay. They tend to have more charge backs and most of the "system abuse" I deal with are small time freelancers trying to squeeze my product's free offering. Don't offer too much for free. Don't be a charity. Serve businesses, they pay money.
3) Don't be afraid of competitors. My largest customers are in fact competitors that leverage my service to better their own service.
4) Don't charge too little. When I first started, my offering was incredibly cheap ($9 per-month). It certainly helped bring attention to my offering and I got a lot of customers for it, but they were cheap customers (see point #2 above). Today my lowest offering is $39 per-month and I seem to have weeded out most of the bad apples (though some still get through).
5) Reach out to customers directly. Don't rely on ads, social media posts or other fluff. I haven't done a single ad or social media post (I don't even have social media profiles). What I did do was directly email/message potential customers.
If I may ask, for point #5, do you mean cold emailing here? If so, how do you differentiate your email with that of other generic cold emails? Or do you just email people you already know?
It really depends on your customer. In my case, I did cold emailing. I was able to narrow down my customer by their job title/role and knew exactly who to email.
I don't really buy into gimmicks or tricks to differentiate my emails. You can read a lot of "tricks" out there, but they come across as inauthentic to me and that isn't how I wanted to establish a business relationship.
The thing I did was send very targeted emails (to people I honestly believed would benefit from my service) and every email was personalized (and I don't mean using a template and swapping out variables). I sent each and every email from scratch, one at a time.
I did read a few books on sales outreach and prospecting ("Predictable Revenue" and "Predictable Prospecting"). They were helpful and I did pick up a few ideas from them, but I mainly took the knowledge and paved my own prospecting/outreach strategy from it.
With that being said, I haven't done any outreach in over three years. All of my customers come to me, mainly referred to my service by existing customers. Or customers that leave a company and advocate for my service at their new company.
I assume you read my submissions and came to that conclusion-- but my service isn't in the ETL industry (although I do process very large amounts of data).
I don't really share my service publicly and maintain a high level of privacy (hence no social media, etc).
I concluded your line of business based on your name/handle: "ELT"
LOL ;)
I value your protectionism yet I hoped to receive constructive feedback. I was only interested about your tech stack, marketing and processes b/c I'm prospecting to become a creator too perhaps in a different niche but definitely ETL-based.
Love that you do this. I have a few enterprise projects that do exactly the same thing (minus the embed in one, just scp and untar). Can’t beat the simplicity.
Regarding the original question we use fiber.io for a few systems and have loved it’s capabilities and performance.
I have never used Jinja/Twig, but I have used handlebars, ERB, JSX and other similar templating systems.
Overall, I find Go's template system to be a bit clunky but it certainly gets the job done. The template system is fairly minimal so it feels mostly like working with HTML, but it gives you a few tools to use.. mainly passing data down the template/sub-templates and the ability to define template functions/helpers. Minimal... but it's all you really need.
I converted my business from Rails 5 to Go about a year ago and the ERB was fairly straight forward to convert to Go's template system.. it felt like I was mostly converting <% .. %> to {{ .. }} and changing <%= render ... %> to {{ template ... }}
My server's binary is more than a server, it can execute one off tasks, etc. For example I can execute the server binary with special arguments, ex "server --task admin-reports" in a cron job.
For the database I use Postgresql with the standard library's database/sql package (using lib/pq as the driver).
For scheduled emails and tasks, I store them in Postgres and I have a task that is run through my server binary every few hours (ex: "server --task scheduled-tasks").
Thing I've observed about pretending to work most of the time: no one notices that you're pretending to work. I still get raises, no one has a long chat with me about my future with the company, nothing.
This strongly suggests that the company just really doesn't expect much out of me for what they're paying, so why should I give them anything more? It's bad enough I have to give them 40 hours (plus commute) of my week when I can apparently get done what they want done in a fraction of that.
Is this laziness, if the alternative is essentially doing extra work for free?
"only" 100 users for testing and feedback? I'd aim for 10 and see if you can achieve that first... it's not that easy to get people to try something, especially if it involves creating an account or installing something.
Some feedback from me, your website is very unclear with regards to what your service actually does.
I honestly love "web 1.0" style niche forums. I wonder if it's the nostalgia of customizing my signature image banner, signature quote and following discussions and arguments, but I love forums!
I honestly considered making a forum (1.0 style) just for myself in a specific technical niche in hopes of people joining.
I have used Nix in the past and enjoyed it... for a while.
I will go against the grain and suggest not using it, especially for native projects of any kind (C, C++, Go, etc). In my case I was doing Go work, but the binaries that are built are usually alright, unless you require Cgo and libc gets linked dynamically (Go will do this without telling you). Suddenly that binary won't work on production! It broke my server and I had to force static compiling so Nix's libc wouldn't be linked dynamically.
This can happen in Go if you do something like look up the user's home directory or cache directory, etc. Suddenly your Go binary is dynamically linked...
Nix handles native projects especially well. For the situation you're describing, Nix would automatically detect the libc dependency from the resulting Go binary. The only possible reason you could end up with a missing dependency in production is when you leave Nix out of the loop during build and/or deployment.
Nix's primary benefit is declarative and reproducible builds. But you can only benefit from it if you actually use it to build and deploy your projects. So instead of copying manually built binaries to production servers, you should create a Nix package and install that to your servers. Alternatively, you could use dockerTools.buildImage [1] to create a Docker image with all the runtime dependencies.
So my recommendation would be to actually use Nix, not avoid it.
I was referring to using Nix as a tool for my own development workflow. You are describing a much more integrated and involved use of Nix (Nix packages deployed to production, Docker, etc).
That only cements the idea of avoiding Nix if you're using it for your own development workflow and the entire team/production deploy isn't on board with it.
The real lesson here is "don't build production releases outside of a carefully controlled environment," not "don't use Nix." What led to the failure was the introduction of local dependencies to the production release. In your case, that dependency came from the Go toolchain that you happened to install using Nix. But uncontrolled dependencies could come from anywhere and the problem will persist as long as you don't take measures to control your build environment. This is where Nix really shines. It creates a controlled build environment. You can avoid Nix of course, but there's no avoiding the problem that Nix aims to solve.
> That only cements the idea of avoiding Nix if you're using it for your own development workflow and the entire team/production deploy isn't on board with it.
I disagree. Using it for your own development is fine as long as you keep it local. Either that or ship the complete dependency by building a Docker image as I mentioned earlier. Nix has various tools to make life easier even if it's only for personal development purposes.
We use it for OCaml because there’s nothing in OCaml that really exist to manage dependencies and build (opam and dune are awful). But it doesn’t work well with our Rust dependency. I think it could work well with our Rust dependencies (which needs to be packaged with a derivation and thus doesn’t work in a nix develop shell) if nix stops where Cargo begins, but it seems like it is not nix’s philosophy.
To say that a build system has nothing to do with dependencies is pretty telling about the OCaml tooling mindset.From Maven to Cargo, almost every modern build system integrates dep management. Only C/C++ is still lagging in that regard.
It’s not lagging. How you install dep as conceptually nothing to do with how you link and build. You can tell dune to use dependencies installed with opam easily enough and opam takes care of managing and locking transitive dep. These are entirely different concerns. I am tempted to say "Kids these days" but that wouldn’t be condescending enough.
as the other comment says, you can't have a build system that doesn't care about dependencies, otherwise different environments will use different dependencies to build.
