Technology is usually just a means to an end. Unless IP is what you are selling, boring is great. I’ve seen SO many teams burn SO much energy on complicated stacks just to drink kool-aid. It’s mind bogglingly frustrating, especially as a contractor. At the end of the day it’s great for me: I get brought into shit shows to clean up the mess. But deep down, I want projects to succeed and clean/sound systems architecture is how you do that. Doesn’t matter if it’s PHP, Python or Java.
It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.
Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.
Yes! So much this. Every startup I've worked with regretted choosing a trendy tech stack early on. Speed of development is BY FAR the most important thing and the SPA/Javascript framework de jour trend of the past few years is an antithetical to rapid iteration. As a consultant, I'll happily bill hours to untangle that mess, but it's very frustrating to see startups with lots of potential spinning their wheels with unnecessary bloat on the front end.
Totally disagree re. SPA frameworks. Having mastered one of the popular ones, I've found I can now turn out fairly complex apps that I never could have contemplated building solo a few years ago.
And then 3 years later after you moved on someone like me has to come along and cleanup the project.
The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing)
I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,
how is that any different from a custom rails server with dozens of gems that need to be upgraded. how do you build a site without any of these risks and make it last for a decade or more?
By choosing a language with a large standard library and then relying on that library rather than on frameworks of the day as much as possible.
For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.
From what I remember of php applications written around 2009, a lot of them had SQL injection and bizarre roll-your-own-security vulnerabilities. There were some pretty appalling things like the same (wrong) CSRF token validation code being copy-pasted into fifty different files, or passwords saved in plaintext, or customer credit card info sent over email, or every single site being mashed into joomla and drupal no matter whether it actually fit and then never updated.
There are a large number of non-professionals and beginners coding in PHP, they start from say an existing WP plugin ,open it in notepad and start editing until it works,
it happens in JS land too, find some js package made by a newb and run a linter on it, I see issues on code that is written by coders with a few years of experience where they do not use properly the array functions, do not use correctly the lamda, they copy paste same code in 3 or more places.
Do you think that all js,Ruby or Pthon dev would properly use SQL without an ORM? I dpn;t think so, I found recently bugs in a JS codebase where file upload would fail if the file had non US characters in it's name because some parameter was not url encoded, so all developers make mistakes and ORMs were not popular at that time to prevent this kind of mistakes for SQL.
These are all examples of pretty amateur mistakes. This reads more like an argument for keeping senior devs on the payroll than a warning about not using a framework.
A framework will not prevent things to become a mess, in the angular project I inherited in most places the rootScope is injected everywhere, I do not blame the developers either, the angular architecture is not great and when you have a lopt of new tasks for you to implement you don't always have the time to reimplement things, but sometimes the correct solution is not used , though you may want to claim that your favorite framework makes it harder to do the wrong thing.
and yet, a lot of vanilla PHP is a mess of code whereas when i had to work on a laravel application i found it a pleasure to work with (even without having any prior PHP experience)
I agree with you, but what sucks is that instead of 1 or 2 frameworks that are stable you get a large number of them that get deprecated, I was brought to work into 2 PHP projects, one was using yii1 and the second Silex , both frameworks were deprecated and some of the dependencies are deprecated too. I did not worked on Laravel, I hope when I will it won't be again on an unsupported old version.
Also it sucks when you search for help and you need to double check if the solution is for yii1 not 2, or angular1 not the others etc.
that is very true. at least angular1 was stable for quite some time i'd say, it was quite usable until they started working on angular 2.
that means when selecting a framework, don't pick the newest, but look for something that promises stability, and then stick with it. i picked aurelia to once angular 1 was no longer usable. and although i mainly chose it for other reasons, it looks like it will be a stable choice.
It could be a good stable framework,
though can you put yourself in my place, say in 5 years you are called to work on your current project, some new small feature must be added or some bug needs to be fixed. So I will have to learn to work with yet another old framework that is no longer populkar and the developers that wrote the code moved to the next cool thing.
It is what it is, I will have to learn and maintain others code like I always done but it would be better if we had some stability as I mentioned, some standard web framework built in JS and browsers that most developers would use and the devs that want new and shiny could ignore that and use whatever.
well, one of the key things of aurelia is to use standards as much as possible. so as javascript evolves aurelia will pick up on these things and remove any homegrown things to use whatever javascript provides instead. so it is up to javascript to grow a decent standard library.
As the other mentioned there are other devlopment stasks that are stable, to give more examples but not for Web, you can get ther code for an old .Net,Java,Qt application, download the SDK used for that version and just build it. There are not 100+ things you need, the SDK contains the compilers, a huge standard library other build tools. If the project had other dependencies those are some standalone .dll or .jar files that you place in the application folder.
For web when I inherit an older project I need to spend a lot of time in finding the correct version of things, like for an older react project it was using an official jsx transpiler but today that package is deprecated you can't just npm install it, so I would have been forced to upgrade the entire build system to use the new thing , but at that moment I had to fix a small thing so I found a hack for the issue and postpone the fixing of that issue.
What I think Web needs is some standard framework, or a framework core maybe jsx or other template thing but something standard to be used in mst projects and for side projects we can toy with the shiny new frameworks and languages.
It is missing a lot of stuff, like I want a modal popup, I need to search the web for a solution,
I want a DataGrid with sortable and re sizable columns, i need to search the web, find something that is compatible and also make sure the license is compatible
I want a basic Dropdown widget that can do basic things like ex have a flag+country name or have a list of fonts where each font is using it's family to be rendered. Also the scrollbars can't be themed for when elements overflow in all browsers so you are forced to find something that reimplements the scrollbars.
When I give example of Qt,Net or Java I include the full SDK , if you did not worked with this kind of SDKs maybe you worked with Android one, basically you have the language STL plus anything you need from file I/O, Networking, Widgets, to the serial ports,screen, and a lot of things, you don't have to package install a new thing for each feature.
Sure it is not perfect, but it is still a lot better than any framework as a long-term viable foundation.
All the stuff you mention can be solved with simple libraries, maybe you could push for a library that solves such problems to be widely adopted. But frameworks always bring a new set of problems of their own, which is why no one is ever going to agree on the subject of those.
There was a lot of JS the language progress but nothing that adds this kind of features. Browsers need to fix those bare bone widgets like the select, the scrollbar, add GridViews etc otherwise developers will use some random, low quality ones .
There is no need that browsers select things that are agreed but 100% of people, it needs to satisfy the needs of a large majority that need to create boring and stabe websited or applications.
ok, so essentially the problem is the fragmented development and feature libraries. that is a fair point. let's hope that some javascript frameworks develop into that direction.
React feels safe to me at this point, look at all the JS frameworks it has coexisted with that are now virtually unused. It is stronger than ever and I see it’s future as more of a jQuery than an Angular 1.
Completely agree. My default stack is now react + an api in the backend. The way you can reuse components is a great time saver (even for simple apps). I also like redux-thunk to separate all my API calls from the components. Makes everything very lean and readable.
I feel way more productive today than in the old jQuery, knockout messes
I've started to use TypeScript and React on the front end, with a JSON RPC middleware on an express server with helpers that automatically implement service interfaces for API calls, action creators and reducer handlers. And all of them are type-safe.
I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.
I'm currently working on various projects at work that I cannot discuss here, but in parallel I've been working on an express / TypeORM / React (SPA & SSR) framework that I hope to release one day as an open source project.
The main focus is to:
- easily share React components that use Redux state and actions between projects
- rapidly develop new server-side services and immediately use them in React components (by removing code duplication
when it comes to creating action creators and action types)
- have type safety
- provide basic server-side and client-side components for basic user actions such as login, user profile, etc
- make it easy to write tests
And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)
Haha, I guess it is not at the moment, but it keeps me amused. In the first post I was just referring to using JSONRPC over standard REST endpoints as the time saver.
Same here! What's your choice of stack for the api?
PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).
Django-rest-framework is super productive once you learn it. It has a bit of a learning curve, but it’s worth it if you are writing a lot of APIs, especially if you’re doing a lot of CRUD.
It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.
thats probably due to having more expirience, but you still have to do the crud yourself and all the other things that you otherwise would get for free.
i like next.js now but for simplicity's sake i think parrent is right.
For my past six or seven contracts I've been carrying around the same set of fetch util functions I wrote in ES6 a few years ago - it's less than 200 lines of code. If the API endpoints are ready to go, CRUD is the easy part. Which tools would you consider CRUD as something you get free?
It's a bigger investment I would say, but once you build a very well defined api structure and frontend components, things start getting very fast to develop.
Also you get the added benefit of completely separate front and backend logic which is very useful in a multi developer environment.
The only problem I see with rails is that it's hard to find devs these days (at least in Europe). Even if they could learn Rails for that project, many I've spoken to wouldn't want to take a job where Rails is required. I just witnessed a project switching from rails to React (for the frontend) because they just couldn't get enough good people willing to use Rails.
That's interesting. This year, for the first time, I've been working with Rails. It wasn't my choice but I've really enjoyed it. A lot just makes sense and it's been so quick to get things from idea to code.
I don't think devs hesitate because Rails (or Ruby in general) isn't good, they hesitate because they hope to gain more relevant experience by working with JS frameworks.
But again, that's just my experience, it may differ for other companies and/or regions.
I heard this before, but when we tried to find a React dev for the front-end part we couldn't find any either. There are more JS devs for sure, but you also compete with literally everybody for talent.
I kind of get the impression that there is a glut of developers who know/are learning React and a glut of companies that are having trouble finding someone willing or able to use React (at least where I'm located).
> The only problem I see with rails is that it's hard to find devs these days (at least in Europe).
If you need a contractor to help with a Rails project drop me a line (my email's in my profile). Been working with Rails since 2.x days. Not in Europe tho I'm GMT-4.
Why is HN so against people who _enjoy_ engineering? Why should I run some run-of-the-mill stack that has enourgmous legacy cruft and just not "fun".
Not every business wants to be sillicon-valley optimized money farm - some people want to do some enjoyable work.
Dear, for your sake only, I am pasting this definition straight from wikipedia -
Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build, and test machines, systems, structures and materials TO FULFILL OBJECTIVES AND REQUIREMENTS WHILE CONSIDERING THE LIMITATIONS IMPOSED BY PRACTICALITY, REGULATION, SAFETY, AND COST.
Yes. This. There are only 700 software engineers in my province. I'm pretty sure not many are working on front end web development. Yet every front end job posting is "engineer". Just no. You don't get to call yourself a doctor because you are medically-inclined. Same applies to engineer.
... and bridge designers don't design 'to have fun', but to have structurally sound, cheap and reliable infrastructure tool to cross rivers. Or imagine hiring a construction company for your dream house, realizing only after all is built that they were experimenting and 'having fun' with new unproven materials, construction, wiring etc.
OP's approach is mighty fine for his own endeavors, but if I had such a worker hired, there would be a serious talk about priorities. If no agreement is found even 100x engineer would be let go.
Quantum bridge: its in a superposition of open and closed and will collapse to one of those states when you try to cross. Also its made out of glass and runs on the block chain.
For a hobby and for learning it is absolutely fine. The critique is on businesses running that way fmeither since some developers want to drink the cool-aid on the job or since the company wants to be "attractive" riding the hype train. (How else could they attract the best developers? ;) )
Because real engineers enjoy making hard things boring.
edit: to be clear, I'm not claiming to be a 'real' engineer. I love writing whimsical, complicated stuff if it makes things easier for users, and make sure I'm writing maintainable code my colleagues are comfortable with with code reviews and removing as many flourishes as possible.
If you want to hack on new technologies, great, that's understandable. But do that on your own time, not when you're being paid to achieve business objectives.
Clients are usually not hiring engineers. They have opinionns on management, on what should be done, on how you should work and in which conditions. They have opinions on you being remote or not, on how you should look like, on your mental health (cf. some pieces on whether people on the spectrum make better employees).
Most of these opinions are not grounded and you can not leverage the related tools to improve the work process.
How surprising is it that, given how few variables we are left with, these variables are heavily over-engineered?
Those restrictions you describe are classic hallmarks of a toxic workplace IMHO, and somewhere I would leave as soon as I had the chance. I guess I'm lucky to have that choice.
Assuming your field is web development, what is not a niche skill? It seems the choice of backend frameworks is somewhat fragmented with no clear default winner.
I'm not a Rails developer myself, but definitely noticed a lot of demand for Rails work in the various remote job newsletters I'm subscribed to. Can't say how much is legacy vs greenfield or whether this is a reflection of demand for a niche skill or that Rails is still a popular choice for companies. Either way, makes me regret a little I didn't stick to Rails development years ago as it seems quite lucrative even today.
RoR is absolutely not a niche skill-there a huge companies using it (GitHub, Shopify), tons of conferences on it (and a lot of Ruby conferences are heavily Rails), and my company personally has had no trouble recruiting devs. StackOverflow puts it at 8% absolutely popularity while Express is at 17%, so just little less than 50%, so it’s not niche just not in the top 3 backend web frameworks.
However, the post indicates React + Redux for the front-end. Perhaps it's my bias as a back-end curmudgeon, but those strike me as _unboring_ choices in the front end, particularly if you're not targeting SPAs.
My point being: one person's "boring" could be another person's anything from "clunky and archaic" to "faddy" to "efficient and sensible." Not even Rails, built upon Ruby's idiosyncratic blood magick, is an entirely uncontroversial choice.
I agree with your overall point, however I disagree with the "just pick Rails and don't do SPA" part. For startups or any small team, the right approach is whatever boring technologies the team is comfortable with. If that is Rails, great! I personally don't know it so that would be a horrible choice for me. Likewise SPAs are comfortable and easy for me (aka boring), but a bad choice for someone else who isn't comfortable with them.
I think Phoenix LiveView is offering a very compelling value here. You are basically writing a regular server side app that will perform on par with SPA for most use cases.
I’m not sure if you’re familiar with what Rails really is. It doesn’t have an admin panel.
Node is a language that you could compare to Ruby.
You can ostensibly do the exact same thing with Node that you could do with Ruby on Rails... but you’d be reinventing the wheel all over the place and duct taping lots of different modules together that all utilize different design patterns.
If you’re good at designing systems, you can do it just fine, albeit slower than I could with Rails. But it’s possible. I have nothing against Node but there’s a time and a place for all tools. Getting an MVP up is not one of them, imho.
I wonder what is wrong with single page apps? As I see it you can largely write the same code, you just have the additional option of modifying the page on the fly.
Nothing "wrong" with them per se, but in terms of system complexity, you're basically doubling it by having application state and logic on both the backend and frontend. When I work on a big SPA, I feel like I'm working on two applications and have to worry about syncing state and logic together.
Nothing wrong with it if you know what you’re doing and have a strong API to power it. Most people don’t know what they’re doing and end up with a duct taped ball or spaghetti. This tendency is compounded when you’re in a hurry to get shit done.
Nothing better than having to maintain 1000 line components. I wouldn't know, but I have dumped them on other people. It made sense to me when I frantically wrote it, how bad could it be? /s
But is the server side method less spaghetti-prone? I'm inclined to believe that you just believe that because it is the way you are used to programming. A beginner will write spaghetti no matter the job, no matter the tools, no matter the method.
I would go with spring boot.
Sure rails is a faster start, but when it grows it becomes a mess.
Spring boot gives you the fastest start in JVM-land, and if your product is successful and you need things to scale, or features are getting complex, you still have the spring framework in the insides that you can manage. Boot is almost just defaults.
But spring boot wouldn't exist, if rails didn't change the landscape of web development.
I ran a small company like this quite successfully earlier in my career. If you think this is awesome what goes unmentioned is how lonely it can get. Also, any issues you have (business or technology) you bear the brunt of alone. A coworking space doesn't really help either imo, if you like working with others you will miss having coworkers. Just something I think worth mentioning if you think this is something you might want to pursue.
This feels like bragging but I also run a one man company and the loneliness is what I enjoy most. Granted, I only work from 08:45 to 14:30 and some hours in the evening, because I bring my kids to school and I pick them up in the afternoon, but the hours when I’m alone, I am 100% productive. When the kids are at home I mostly do some kind of manual labor to get some sort of exercise. Right now I’m building a shed. Last year I built my home office/guest house.
To make up for the missing social interaction I play football with friends, do some consultancy jobs on the side and I help where I can with my son’s football club.
This really is my dream job and I enjoy it thoroughly. I have no problems staying motivated and every day I have loads of inspiration.
The moment I lose motivation will be a sign for me to sell everything and start something new. I ran an online marketing company before this and that was really exhausting for an introvert like me. Selling that company was the best decision I ever made, apart from marrying my wife.
You have described exactly the kind if work/life balance i desire! I do enjoy a lot working alone since i've got family with little children too. I won't add any value with my comment, i just wanted to thank you since it feels just a little bit easier to know somebody else is having what i want: one day i may have it too.
I'm not criticizing your preferences at all, but I think it's really strange for you to describe them as loneliness. I would say you work alone, but you're not lonely, because you have a bunch of other social connections in your life that for some people are replaced by coworkers. If anything, your comment reflects a kind of strange default on HN where work consumes so much of your life that coworkers are your "friends" and working alone is the same as being lonely.
I should have quoted that word. What I prefer is the fact that it's quiet, I don't get interrupted, I can set my own agenda and I never have to go to a meeting that messes up my progress. I like teammates and coworkers, I just don't need them to do what I like to do.
I found that having 10-15 employees (and working for clients instead of yourself) took all the fun away from the work I enjoyed most so I started designing/developing/marketing my own projects as a hobby. It was already earning a living wage by the time I sold the company, and it was always my plan B. So when I got the chance to sell I did not hesitate.
Super broad question here but how do you guys do it? I mean, how do you go from knowing how to build a basic webpage to knowing that you need e.g. Elasticsearch for search queries. It seems like there is so much specialized tech to learn but no obvious learning progression path.
I only learn when I have a project in mind that I want to do. No matter if it’s work on or around my house, creating an app or designing something like a logo or interior. Then I just start. Walk into a wall. Stop. Look for learning material or inspiration. Start over.
Reiterate. Learn more. Reiterate.
I’m not easily frustrated by failure, starting over or general lack of progress. If I have an interesting goal I just keep going. It might not be the most efficient way, but it’s how I learn best.
---
There is no magic bullet. It's a combination of inspiration, motivation and perseverance. Example: I spent 1 year learning to built an app in Swift (together with a friend, one evening every two weeks), then we decided to ditch most of what we learned and start over in Flutter, knowing that it would take us another year and I just don't care. I'll get there eventually.
Started january 2016, so I’m almost 4 years in. I’m actually thinking about dropping some consultancy clients so I can focus even more on my own projects.
I get that it’s not for everyone but I grew up on a farm so I kind of got used to the quietness early on I guess.
I have developed a network of websites (communities and marketplaces) in several very specific niches, all focused on the agricultural sector. The revenue is mostly coming from subscriptions and Adsense.
The hardest part of building this business is to keep motivated for a relatively long period of time. I'm still early in this startup journey. This is only the 2nd year of me working full-time on Listen Notes.
I think it would be helpful to surround yourself with like-minded people (online or offline) -- we are social animals. Indie Hackers is pretty good: https://www.indiehackers.com/
I live in San Francisco and I used to work for companies, so at least I can often hang out with some friends/former coworkers who are doing startups or working in tiny startups.
In my coworker space, people from different companies rarely talk to each other...
Why did you choose to have ec2s with postgres rather than using RDS? I've found it saves me a ton of time dealing with upgrades worrying about backups etc to have RDS handle it.
I love RDS, but having maintained complicated Postgres setups before (at my previous employer we had a few dozen Postgres servers for different big clients, all set up with replication to different geographical locations etc. as well as automated log shipping and backups going to a "homegrown" blob store), it's not that much effort.
What you gain is the flexibility to control e.g. which extensions you want to run, and exactly how you want to set it up. How important that is really depends on what you want to do.
Not OP, but I set up a SaaS platform, and I also ran on straight Postgres (RDS wasn't an option, we weren't on AWS). In my experience, after setting up WAL-E to continuously backup to S3 and giving it plenty of extra disk space (for stalled WAL segments), it worked pretty well with no intervention. Restores occasionally took a bit, but they never failed (we managed a couple dozen databases over five years).
If you know what you're doing (important qualifier), I'd imagine cost is a huge factor too. RDS is pretty often a significant % of your AWS bill - how valuable this is, entirely depends on how confident you are doing it yourself.
Hey, thanks for building LN. I was actually admiring the site design just yesterday while I scrolled through some episodes. "Dang, I hope I can build something like this one day."
You managed to pull me away from my previous preference, player.fm. Good job!
Interesting to hear that your WeWork building isn't an especially social space. I know you talk about why you picked a dedicated office in a coworking space over coffee shops etc., but why did you pick WeWork in particular?
At the 4 year in make building a professional services firm in Shanghai, old school work, but looking constantly for online B2C and B2B opportunities, I love IH for the community aspect. Although I find one has to be careful with balancing the amount of work allocated to seeing what others are doing and the hard but inevitably more important grinding out of one's own business aspirations. Great conversation!
Was it hard to come up with the idea and believe in it enough to pursuit it to where you are today? I think self doubt must be a challenge, especially when you are alone and still far from a proven concept and nothing so show to customers. Was this idea the only one you evaluated before you chose it or did you also have other ideas, of which this one you liked best?
Hey wenbin (and any others pursuing indie-hacking), I run a virtual meetup about once a month you might find fulfilling for meeting like minded people.
Yes, the worst thing is the huge amount of decision making even over very minor details that has to be done all the time. Coding and maintaining the servers isn't even that difficult. It's all the little stuff like scheduling with clients/vendors suppliers, wondering when is a good time to chase that invoice, which words to change in your proposal for this client, and so all. If you have employees, how to manage them, how to review their work, how to mentor them. It really is death by a thousand paper cuts.
What can help with this is to start building little systems and solve these problems in general.
Dedicate a given day of the month or week for all your meetings so scheduling is simpler.
Chase invoices on the same date every month, chase all invoices that are overdue by some threshold you have set. Just follow the rule, and chase using a template. Perhaps even code the first few chases into an automated system.
Try to avoid customized proposals, use templates for many things. I agree this one is hard.
Managing employees, you have to consider each employee is a force multiplier. The idea here is to invest a day to get a week or similar.
Overall, you need to just invest a limited time into each decision. After that time, go with what feels best even if it isn't perfect and move on. I find the same thing hard myself.
My company's Slack is just me and ~12 Slack bots all doing various things (reporting subscription changes, feedback, bug reports, error alerting, CI status, etc). It's amazing to look at and functions immaculately, but occasionally does have the grim reminder of just how alone it is being on your own.
Especially when you think "this all works great, but would still work equally great with another human or two here."
Dude, I would love more insights on this. I have trouble finding assistants for the most rudimentary stuff and am constantly looking for IT solutions. Please, please, please. Maybe an HN post?
I started a Medium draft a while back just detailing what all bots I use and how I organize all the channels, but it honestly felt pretty boring/droning.
I'll see if I can clean it up and finish it though; if you have any particular questions you'd like to see included (selfish: so I can feel like it's less braggy and more interesting), I'd love to hear them. Contact info is on profile if you don't want to derail this thread. :)
Years ago Joel Spolsky on his site "Joel on Software" had a "Business of Software" forum where a lot of very small ISVs hung out and discussed items of mutual interest. Anyone know where those kinds of folks hang out now to discuss things?
Some people enjoy being alone, others don't. You don't know in which group you are until you experience it.
Unlike you, I wasn't running my own business, I was just working remotely for a company where the HQ was on a +12h timezone. I felt the exact same way, even if I was working from a coworking space.
The lonely aspect is incredibly difficult, especially if you're an extroverted person that draws their energy from collaborating with others. I also find the lack of accountability to others as hard. I know there are services that cater to this type of founder/freelancer.
I have found that running a twitter account is helping for this. I have <20 people following and their encouragement that my stuff is not total rubbish really helps.
The part that I find the loneliest is making all the core technical and business decisions by myself. I really miss being able to bounce ideas of a partner.
Sure, you can do it with friends etc. But at some point you just become menace asking them to think about your stuff so much.
I used to do this with a friend, for me thinking about his problems was refreshing. We worked in different domains, so it felt like a challenge not work related.
"I ran a small company", what happened? Why did you stop or did it get stopped? What was the reason?
One man show / sole proprietorship is great, but its bad for family life. It's 24x7. Atleast thats how I saw my dad, dining room was the company meeting room and we all are unpaid company "helps",assisting our Dad support the family. This is the main thing that holds me back from being an entrepreneur (sole proprietorship 2.0).
you don't have to do it that way. i run a company, and i don't get my family to help me. as long as i earn enough money to cover the family expenses, i don't need to work crazy hours.
i get to take time off whenever i want, or whenever the family needs it, and not when my boss allows it.
are there any groups out there for the small technology business owner? i'm extremely hesitant of asking about this because it's a fine line between brainstorming technology problems with like-minds and getting owners who want you to problem-solve for them.
Mind expanding on the coworking bit? I always think about hitting up a coworking just to have some human contact when I'm working on a project. I've yet to actually do it however.
it depends on the co-working space. at a wework place i found everyone stuck in their little offices, and hardly any opportunity for interaction.
at another space i find people are more social. they organize events, coding workshops, even cooking classes, occasionally they cook meals. there is a fully stocked kitchen that everyone can use whenever they like. just pay for materials used. people often go out for meals together. etc...
when you are working, people will leave you alone, but if you know who else is there and what they do, you can talk to them and help each other. it helps that many are freelancers and not secretive startups hustling for investment money.
Agreed. Part of a two person team, but the other is mainly on the business development front and I'm the main designer/coder.
It's so hard sometimes. No one to really bounce ideas off of, every little thing you have to do yourself. Staying inspired to work is sometimes difficult, because you are literally doing everything yourself it just gets so overwhelming.
Agree. To learn all of this as a single developer is not an easy task either. These are real frontend, backend and devops languages, frameworks and tools. It takes time to learn.
I second that. This seems really full stack as you can get, but I'm not really a professional dev by training, so I don't know if most people are this hardcore. I built and host some web apps myself but everytime I have to switch from doing something front end to back or vice versa I find I need to refamiliarize myself with a bunch of stuff and have to stop myself from panicking
It sort of depends, if you’ve worked in a couple of corporates where you have to know a handful of various tools at each it quickly adds up to having enough knowledge to quickly deploy even what hacker news considers ‘heavyweight tooling’. Most of these tools have QuickStart guides that do get you most of the way there for a basic use case. I’m running a similar solo project with an almost-but-not-quite similar spreads of technologies.
But as I said, it depends on your history and what you work quickly with.
In the article the author says they chose Ansible because docker felt too heavyweight and unnecessary. It’s true that docker has a lot of stuff you don’t need in there, but trust me when I say Ansible is no picnic. In fact I find it easier to take what I need with Docker and Kubernetes and get running way quicker than I would ‘naked’ Ubuntu machines that I need to semi-manual previsioning with shell scripts or Ruby scripts. I got up and running with Kubernetes on DigitalOcean in less than a day, and Dockerfiles using familiar technologies I’ve used before take less than an hour to iron out.
You’ll get people who say that Docker is overkill and unnecessary and far too complicated for a solo project, but then you’ll get others who believe it’s a small file with 20 lines of declarations, sat alongside a 30 line yaml file that can provision all of your infrastructure instantly across any cloud provider you choose.
Indeed. He mentions halfway down his previous employer is a billion-dollar startup, and why what works there won't work for his micro startup. And yet ... I'm sure a lot of what he learned there is being applied here.
It’s doable for someone with several years full-stack experience. I had worked with all of those systems and more by the time I had 4-5 years experience.
I do this stuff for a living and man is that a lot of stuff for one person to be responsible for. He could probably be a CTO at a lot of big companies making more than he’s making now probably.
This seems super complex to me. I am a single dev that runs a $30k\mo software based company off of PHP+MariaDB+bootstrap+jQuery+few other plugins. Hosted on a managed HIPPA setup. The firewall+app+DB servers run me about $550\month and I have excellent support. I spend effectively 100% of my time on business logic\ui and zero time keeping up to date on infrastructure (and learning it). Which means my customers benefit from me fixing problems and adding features. Kudos to what works for you....super great... And, for me at least...it is even more "boring" and awesome.
VMRacks (now hipaavault.com). I'm not affiliated, just a completely satisfied customer. As to setting up the business, I would also recommend a HIPAA auditing/hand-holding company. I use Compliancy Group (https://compliancy-group.com).
Just finished my undergrad in cis, and have been grasping at the many services in the industry. How did you find yourself in freelance within clients needing HIPAA compliant?
I am surrounded by people in the primarily private-pay Mental Health space because my (romantic) partner is a consultant in a tiny cottage industry. In my case, it's 100% "people you know". Dealing in PII suuuuuuucks because I constantly have an elevated anxiety about it. However, if it wasn't PII plus the people I know and met......then I probably wouldn't have the opportunity I have.
That said.....had I not done "this", then I probably would have done something more lucrative and "easy". I see non-PII opportunities everywhere, and (mostly) only hang around because what I do now pays the bills.
similarly , making half that and using dedicated servers. When you re a solo dev you dont really have time to risk learning unproven tech or tech that doesnt scale. And as a dev i like writing code that does new and interesting things, not learning tools and other people's APIs. The amount of services this guy has to manage is mind-boggling, and unfortunately i m simple and stupid. I guess i m a hermit dev but thankfully i ll never need to work for others again.
All of that is a very typical Django stack with React bolted onto the frontend. Whether he runs into trouble managing RabbitMQ, Redis, Postgres or any of the Python services is another story, but at least if he did there are many, many others using the exact same stack, so he should be able to easily find answers to people experiencing the same problems. All of these technologies have several year track records now, too, so (hopefully) they are stable and reliable in production. My biggest concern would be managing the ES cluster.
On the other hand, I disagree with his points about docker being overly complex. Docker images are simple. Kubernetes, once you get the hang of it, is great on GKE and gives you automatic SSL via Google or let’s encrypt, and load balancing and auto-scaling just works. It’s probably more expensive than managing your own servers, at this level, but maybe not since you could pack more services into fewer compute instances.
I love these stories. I'm a one-person company too: contribsys.com.
My production server stack is Apache + some Ruby CGI scripts, to serve static files and handle billing webhooks. I spend less than an hour per week on devops maintenance.
KISS is the #1 principle when scaling a solo operation.
Didn't ruby remove its CGI libraries from their standard library somewhat recently. I believe there were mostly helper libs, but I am curious how that works.
CGI is just running a program in response to a request. Things about the request are put into environment variables and POST/PUT bodies are on stdin. Your program writes HTTP headers, two newlines, and the response body.
You don't need libraries. If you have reasonably low traffic CGI can get you really far.
> If you have reasonably low traffic CGI can get you really far.
And even after that, I would expect that CGI augmented with some careful caching (read: all static content and some dynamic content with sensible expiration policies) will get you even farther without having to dramatically change anything.
I built an app in Perl/CGI::Application for a company which ran media campaigns with national brands over a 12-year period. It's not the fastest option but it certainly works.
CGI is still in the stdlib, and AFAIK there's no plan to deprecate it. You might be thinking of a few other methods like URI.escape that have been marked obsolete in favor of CGI equivalents.
Hey I thought I recognized that domain, yay sidekiq! Keep up the good work. By the way we're seeing issues with contrast security gem and sidekiq, but we're pushing on contrast not you.
sidekiq! Interesting wenbin also wrote a task queue system... must be something about that type of engineer that leads to this pragmatic tech strategy.
I thought I was reading my own blog post :) We use very similar tech stack at my current company:
- Ansible for provisioning
- Python/Django for website/api
- VueJS for frontend(where needed, some pages are simple Django templates)
- Celery for background work
- uWSGI and Nginx as servers with AWS Load balancer
- Elasticsearch for search
- Redis for caching
- Postgres with Postgis as main datastore
- Datadog for monitoring
- Cloudflare for DNS
Some differences as I am working with a team:
- We do use multiple branches and git tags for releases. Feature branches are also common as multiple devs maybe working on different features.
- We use Gitlab-CI a lot for testing and auto-deployment(ansible script can be called from our machine as well)
- Terraform for infrastructure provisioning. We have stopped provisioning any AWS service by console. Once the service is provisioned by terraform, ansible takes over.
I have tinkered with Docker, Hashicorp Packer but this setup has been dead simple to reason and scale reasonably well.
How do you feel about using a dynamically typed language like Python for all your backend code? Whenever I had a codebase that grew past several thousand LOC it became pretty unwieldy pretty quickly for me personally. I'm curious if there's a conscious tradeoff for people using Python/Django to start because it's really fast to get up and running with (for existing or new devs).
I don't think typing is the problem you make it out to be. You can specify types in Python, and mypy will type check for you. And nothing about Python means you'll have an unwieldy code base, I can only imagine you'd have the same problems in Java.
The real reason to switch would be performance. The interpreted nature of Python that makes things like Django and PyUnit possible also makes it kinda slow. Some places choose to parcel out a few key services in a faster language (C, Rust, Go) and use bindings to call out as needed.
Completely agree, and I'd like to add that it should only be broken out when performance is actually a measurable issue and there's a good business case for it.
A lot of people get caught up on "x is slow, y is fast" and try to over-architect too early on, then end up focusing on the wrong parts of their product, and sooner or later the project falls apart.
Not OP, however it is fine. I worked in a similar stack as OP with a small team (however it used Ruby/Hanami instead of Python/Django, and of course the difference between both stacks). The code had ~100k LOC for the main service (we also had some other services that had dozen of thousands LOC) and it was completely fine to maintain. Most errors we had wouldn't be avoided by static typed since they're logic errors, not programming errors.
Sure I prefer static languages nowadays since I work in a much bigger company, however I think the benefits of static languages is overhyped.
For us, we follow a very tight convention around how we write code. This has helped us in maintaining the codebase. Of-course some tools help a lot too:
- We use standard tools like flake8, isort, black for code linting.
- We are not following TDD, but we do write tests for all features. Pytest helps here
- Proper code reviews. I cannot stress this enough. As a Tech-Lead I have pushed for code reviews even when working on (supposedly) tight deadlines.
- We are also exploring to use type hints introduced in Python3.7.
PS Shout-out to Poetry(https://poetry.eustace.io/) to make our dependency management easier than ever. Updating third party libs is a lot easier now.
We’re pretty much the same - except for Poetry where we are still using plain old pip. Are you able to say how Poetry makes updating third party libs easier?
There are four popular typecheckers that I'm aware of (mypy [1], pyre [2], pyright [3], pytype [4]), which is a little confusing, but any of the four will catch a lot of type issues that typical statically typed language compilers would catch. It's not as robust as true static typing - there are sometimes false positives and false negatives - but I find it helpful.
Right - I'm totally on board with the overarching goal of keeping the stack as simple as possible, but at the app level, for the best maintenance story, I would want types.
> with any dynamic typed language you have to unit test every single thing possible...
> ... and it becomes not so bad to work with
O_o
How did you manage to put these two statements in a single sentence implying positivity :)
Why do people choose to explicitly write unit tests over and over again for basic things which could be caught by a compiler?
People are losing so much productivity (both short and long term) and being deceived into not having the type system "stand on their way" while they're typing out the initial prototype.
This always bites back when you start first significant refactoring.
I will never understand the appeal of the dynamically typed language. Modern, statically typed languages with strong type systems, provide so much more productivity, reliability and confidence in the codebase that it is really irresponsible to ignore them nowadays.
Did you do the entire stack yourself, I'm planning on using almost identical stack, but need some help, do you have some kind of blog on howto or recommend one
If you create a course on udemy/YouTube on how to setup a production full stack, there are many basic setup videos or tutorials, but none on production full stack with load balancing, replication, caching, etc
That's awesome and it is a tech stack that I try to mirror and am confident running myself as well!
It's incredible the amount of knowledge required for a single person tho when you think about it eh? It's the full frontend (which I would have more trouble with) + databases + caches + search engine + metrics + deployment + source control + sysadmin all baked in a single person who is also trying to make it a business!
Kudos for the effort and making it happen, one day I might be joining the same journey with the same stack! Just gotta figure out what actually motivates me to build a business on top of =)
as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners.
I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.
Having been the CTO of a startup and then a SWE at a FAANG company for 8 years, I disagree. Being at a startup does indeed require a broad technical skillset, but being effective inside a large company requires a lot of skills (both technical and not) that early startup employees may not have or need. I've grown a lot from both environments.
Are you me? I am constantly being gutchecked that a startup mentality does not fly when you have several hundred million in the bank. That said, my enterprise and upper management butt kissing experience from the 00s don’t seem to matter either. I can stay heads down in code and I’m not in fear over being downsized. The hard part is teaching these young kids how to scope.
And the thing is, generalists do better work. They do less work overall because there are fewer of them, but compare a typical enterprise 50 person team to the output of a team of 5 generalists, hands down the generalists will make a better product every time because there's no buck passing or shoulder shrugging about problems.
IMO, the reduced output of a team of specialists vs a team of generalists has less to do with generalists doing better work, and more to do with it being impractical to hire specialists at lower levels of scale - and higher levels of scale are less efficient.
A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise.
But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists.
(You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)
Completely agree. IMO the optimal efficiency is easily a team of either 2 or 3, with one FE and one BE, and optionally someone doing dev-ops-y stuff for both of them. After that point your 'output per man hours' can only really go down.
In economic terms, sounds like the marginal utility of adding an engineer goes down significantly as companies get larger and past the start-up phase ;)
I think specialists make more robust systems, but generalists get more done. When I work at large companies, it makes me sad how long it takes to get anything done. But once the work is complete, it is really solid. It scales well, it handles edge cases gracefully, it deploys cleanly, all because a large team of specialists made each part of the puzzle work really well.
The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it.
(All of this of course assumes you work in an org with lots of really good specialists).
i agree on this point. having highly specialized SMEs certainly helps with scale, for sure.
iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.
“Every time” until they are asked to build a product that requires a deep specialized skill set.
I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow.
Great teams and companies have generalists and specialists.
You're right. That's been my experience, as well. But... the crème de la crème from FANG are different beasts altogether.
I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability.
It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.
It might take Alice 10 hours to do the sysadmin, 5 for the database, and 15 for the devops.
Bob however can do the devops in 2 hours, sysadmin in 3 hours and database in 4 hours.
Bob is of course more productive, but if you let Alice do all the DBA, then Bob will be even more productive, and the total output of your team will increase.
Yeah, I worked in start ups and that's where I got the fast pace and I think that allowed me to rise to high ranks very fast at bigger companies as I have a solid understanding of all the stack.
In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.
I finally created an account because your comment resonated with me. I have created 95% of my platform by myself which itself was the manifestation of several business ideas. I started out buying servers and starting a dedicated, then vps, then shared hosting farm that requires all of the frontends you mention. I took a different approach, I went all out open-source and spent time creating glue and flashy bootstrap frontends to orchestrate everything reliably.
I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system.
So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)
There are people who create consumer products, and there are people who create the products that power those products. It's no different to when id Software sold licences of their engines to other game developers. Perhaps you can turn your infrastructure into a business of its own.
First, that's a great stack and very well written/presented.
One comment - he dismisses serverless as being overengineering. I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.
One can see from the snapshot the servers are indeed severely overprovisioned and underutilized. Building an api with api-gateway + lambda is less work than running django in uwsgi behind self-managed nginx, and is guaranteed to be more cost-effective for unpredicted load.
Same logic applies to the db servers - why not hosted?
And last - the inf is a good reminder that prefixing your api routes with /v1, /v2 is always a good habit.
Good point! For people who have tons of experience with serverless, serverless is probably a better choice than running servers for some use cases.
As a small business owner, there are two types of cost that I need to consider:
Time: the time I use to do A is the time I can't use to do B. Unfortunately I haven't used serverless so far in my professional career -- in this sense, I'm not full-stack enough :) It takes time for me to learn it, understand it, operate it, and experience various outage scenarios to gain the true learnings. It's more costly for me (probably not for others) to use serverless than the things that I already understand. I'd rather spend more time on other non-engineering things nowadays -- believe it or not, I spend 1/3 of my working hours replying emails :)
Money: the money I spend on A is the money I can't spend on B. I decided not to use api-gateway + lambda & hosted db servers, primarily because of $$$. I actually did the pricing calculation a few times last year. In addition, api-gateway + lambda also require some time for me to learn, which I should use to talk to users, marketing, building new product feature, thinking (yep, thinking also uses some time budget :)...
Just wanted to add another reason not to use serverless, or at least AWS. For small projects I would rather experience downtime than big invoice. I had a project running on AWS, but it turns out you can't limit the budget, the best you can do is make alerts when costs exceed some limits. I have now moved the project to old-skool server and sleep much better since.
I used a bit of serverless Javascript (Firebase functions) in a previous startup, and it actually worked really nicely for small self-contained tasks - saving files to S3, triggering customer emails, triggering notifications or webhooks in other services (and ofc in Firebase, actually doing things with the database, but it's not a fit for everything).
Thank you for this excellent write-up. Monetizing APIs is always a great topic; did you consider or will you consider using a 3rd party API management service such as RapidAPI or Apigee to keep track and charge for API usage?
I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.
I was all gung-ho about serverless for a while. I wanted to release a demo for my product and thought I'd cut through all the hassles of managing my own server.
I found it bewildering. It was a whole new skillset with new benefits, but also new considerations and headaches. When push came to shove and the clock to release my demo started ticking down, I just went back to a linux server.
I use the same linux distro at home and on the server, and there are about 3 technologies I need installed. On retrospect I think I made the right decision, but happy to have my mind changed.
I've yet to find someone explain a serverless API based setup that isn't more complicated than good old fashioned LAMP or equivalent. Serverless seems to always come out more expensive as well.
I've been exploring serverless for a project at work, and this is my conclusion too. It's great that we don't need to manage any servers and can easily deploy tasks with one command - but we already have infrastructure to do all that for that for our existing apps.
For someone starting out you don't need to worry about learning Linux and how to configure Apache to serve SSL certificates in the right way, but that is important to know, unless you are happy to always rely on (and pay for) someone else to do that.
To me serverless is similar to Heroku, it's great for starting out but as you start to grow it's going to quickly become a lot cheaper to maintain you own systems. Except with serverless it's not so easy to self-host because you end up relying on all the tooling the vendor provides.
Not to mention that he might not stick with AWS if he runs the numbers- he might hop ship to a different cloud provider if he gets a better deal. I don't think it's appropriate for such a fledgling enterprise to lock in to AWS-isms so they can keep the change provider cost as low as possible.
Also, people seem to be dismissing the value of a rock-solid local end-to-end dev stack which with the latest iteration of technology I feel has become very complicated and expensive. The OP can run the same Ansible for his dev stack as well as his prod and his dev stack doesn't turn into an AWS bill. Most of the AWS managed tech & services is only reliably testable on AWS at a functional/integration level, which is a cost that a company this small shouldn't have to absorb.
Not sure I agree with the anti-lock in sentiment. It's a nice to have, but if what you know well is AWS or GCP or whatever, definitely lock yourself in.
> Building an api with api-gateway + lambda (...) is guaranteed to be more cost-effective for unpredicted load.
Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack [1]. My service needs to handle lots of really small and simple HTTP requests, and almost every request needs to do a (small and quick) database write. I did napkin math – at the current usage levels, Lambda per-request fees alone would use up significant chunk of my current hosting budget.
Someone who has been doing this for years before serverless existed can set up and manage this infrastructure trivially, using almost no time compared to developing the application and the business. It also provides you with security: you know the pitfalls and the problems with hosting these, serverless is another new technology which can go wrong.
Yes, and no. If you already have a lot of experience building apps that run on servers, there's a learning curve to switching to serverless. Is it huge? Not really. But there are certainly pitfalls and best practices to learn about. The costs can be harder to predict, especially when starting out. And the tooling is different (and much less mature). So now you have a bunch of stuff to learn about or consider, or you can just go do the same thing you already know how to do with minimal friction. It's possible that the cost savings of not overprovisioning servers is worth it, but I don't think it's that straightforward of an answer, and if your server costs aren't massive, you might be better of spending your time building a great product than learning a new way to build.
How? His boxes are running at 100%.
He might be able save some money by switching to hosted db and maybe run his webservers serverless (and creating some keep-alive triggers).
Nontrivial cost reduction would be switching to a different host instead of aws.
As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?
As me how I know. When I was a solo dev doing my own thing, I'd spend way too much time working on things that really wouldn't affect the business but were "good engineering things" to do. If I spent more time working on things that would grow the business instead of wasting weeks writing fancy deployment scripts, maybe I'd still be doing my own thing now!
> As team of one, you have to be very judicious with your time. You often have to have a philosophy of "if it ain't broke, don't fix it". Yeah they could burn a week or two switching over to lambda and whatnot but is it going to have a higher ROI than all the other things they could be working on?
Timeframe has to be considered. If it only takes a week, I'd strongly suggest biting the bullet. A week's budget can be quickly spent troubleshooting issues, scaling servers up and down, installing software updates, hardening systems and whatnot.
It will most likely be much cheaper to run too. Which, in a single-man operation, may be worthwhile.
Think of it the other way round - if your workload is not realtime, but "within minutes/hours", as in processing feeds here - scaling the worker nodes with an ansible scripts needs to be done on maybe a weekly (if not monthly or less) basis and you get 4/3 instead of 3/3 - for a few minutes of work. This just does not seem to be the workload for autoscaling and adding complexity. I've ran a similar setup at a past job - we planned for whatever but in the end it was one person clicking a few buttons to provision a new instance once in a while.
Also some workloads are really bad for lambda, because you can (total napkin math) run 4 cores at 100% load for 24h a day to do your processing, all at the cost of "1 instance".
If serverless were easier, more people would be using it. But it's not simple or straightforward. You have to learn new systems and conventions, it has a bunch of weird considerations depending on the use case, and most people just use it when they don't want to figure out what instance to run some periodic, one-off job on.
It's a niche, just like all solutions that aren't a single Unix process on a single Unix box. Even CGI scripts are a niche. You pick the niche that you know.
I don't know if overprovisioning servers to counter traffic spikes is over engineering, the mental model is pretty simple. May not be as cost effective or infinitely scalable, but it's simpler to wrap your head around.
I take (very minor) issue with your first line and the point "well written" (I do agree with well presented).
Since the author is reading/commenting here, and there was a large amount of space in the original article outlining tools/services he uses, can I humbly suggest they use a tool like "Grammarly" or similar to help with the word-choice(s)?
Some distracting use of plurals for terms - e.g. "traffics", "stuffs", etc - may have been avoided and other spelling and grammar aspects could have helped make this easier to read. That all being said - the 'essence' of the article is to be commended.
Completely agree. Cloud functions are in many cases a better option than maintaining a server, specially for those background tasks that fire occasionally.
The only issue I've found about using serverless is the database. In most cases (Firebase, Fauna, Cosmos, DynamoDB) you have to couple your stack to the DBaaS provider which is not a great idea. AWS recently announced Amazon Aurora PostgreSQL Serverless but while it allows you to use regular Postgres tools/queries you are again tied to AWS.
One hopes that GraphQL abstractions will enable the decoupling. So if you opt for a database that offers GraphQL natively, it might address the issue. You do have to learn the GraphQL ecosystem (new tools/language etc.)
> lambda is less work than running django in uwsgi behind self-managed nginx
If you discount building an AWS-specific deployment process that includes "pip install" from an AWS linux machine image, zipping the project, and putting it in S3.
Yep, learning how to run your own business is the only way to convert 10x development aptitude to a 5-10x pay increase. Otherwise you get 1x pay, 10x the expectations, upset colleagues that feel inferior in comparison, and very little promotion chance because the company needs you right where you are.
Alright. Just make a "boring" website now, it's "easy".
If it's one thing i really dislike within both the scientific and the technological sphere it's this arrogance disguised as common knowledge. Because it's not. Articles like this is nothing but bragging. The author, whoever it is, clearly has a very long time working in the field acquiring this knowledge. Be humble.
To be fair, half of the used services do not have anything to do with the website itself but with the whole business around it. Also, most of the tools do not require a PhD in computer science; neither Rollbar nor Cloudflare are actually hard to set up.
Still, you have a valid point. The setup described here is not boring at all and not easy, I expected a one-root-server-for-everything that runs some PHP and MySQL.
anyone can build a house from scratch! just read the instruction manuals for brick-laying, carpentry, electricals and plumbing. After all, none of these require a PhD.
I'm a one-person company too ( geocode.xyz ). My tech stack is even more boring than that. (Nginx, MariaDB, Perl on AWS Ec2 Linux instances. I don't have an office either.
Picking your stack/architecture based on team size is something most engineers miss.
Microservices, great for companies with many teams. Not so much when it's three people scrambling to create something meaningful. Monolith all the way.
It's funny because microservices are explicitly targeted at solving problems for development with many teams, and lots of single team companies cargo cult them. Did they miss the first paragraph when they were reading up on what microservices are?
- different SLA and scaling requirements per component/endpoint
- different security domains per component/endpoint
- different rollout strategies/policies per component/endpoint (no need to restart your long-lived client TCP sessions in parallel to rolling out a business logic fix)
- ...
I've been happily developing and deploying microservices for small customers, in teams of 1 to 10 people. But I also don't work with customers who just need simple CRUD apps.
Everything depends on context, but I don't think microservices are the best solution. I think in nearly every case there is an easier way to address those problems.
Who says only multiple teams need microservices, and who put them in charge of what people find helpful?
If the 'app' has enough different 'bits' I'd favour a SOA no matter the team size.
Somebody now wants to say that isolation doesn't necessitate distinct services; they're probably right, but the alternative is great discipline - why not make it easy?
It's a form of defensive programming isn't it? - if widget factory shouldn't be using a function from auth helpers, make it impossible!
There are better ways to solve that problem. Different packages, visibility modifiers, using interfaces between modules, etc. Taking a little time to iron out a disciplined process for your team is so much better than using tcp/ip as your process and all the problems that brings.
If you can't trust your team to follow a process correctly, you're fucked in a way microservices can't save you from.
My thought exactly. I was expecting good ol'LAMP or something along these lines. I think here "boring" means "has been released for more than a couple of years".
Thanks, for all of your comments so far on this site. I don't know what you do specifically but what I can glean from them is inspiring to say the least... even the secrets you keep reinforce what I feel is the right way to act.
I run multiple SASSes for clients for myself and clients on far more "boring" stacks than this. One of them still has significant bits of VB.Net!
This post seems like a sea of trendy buzzwords to me. Maybe he thinks it's not trendy because it's not docker/serverless, but to me that stack is mainly a load of fads. React/Redux/Webpack are "standard", damn, 4 years ago you could have replaced that with a plethora of alternatives, as you probably will be able to in 4 years time.
TBH, this is more inspiring than I thought. I thought this would be some BS article about promoting your company but turns out, it was a fun and inspiring read.
My dream is to find a good idea and work solo. It is a little harder as a mobile engineer but you're right as you mention in the blog. There are technology nowadays that help me with backend/dev tools.
This looks like a great service; I just signed up for it and created my own listen later playlist. I spend 6-8h a week on my mountain bike and I use most of that time to listen to podcasts. The challenge with how I do it (using just an Apple Watch) is curating my feed. This is an excellent tool and a far better UI for curating a feed.
I also like the different and varied sources of income that you have, from the transcription service to ads to your API. Seems like you've built a great platform that you can use to experiment with different revenue models.
One additional question - your product is called Listen NOTES. Are you planning on adding note taking functionality to it at some point? One thing that I've always wanted to do was to jot down some set of notes to myself (typically during one of my bike rides). I always imagined that being some kind of voice activated thing, but I'd like that note sync'd to the spot within the podcast that I was listening to (and perhaps transcribed as well). Any thoughts about building something like this?
> Wait, how about Docker / Kubernetes / serverless? Nope. As you gain experience, you know when not to over-engineer. I actually did some early Docker work for my previous employer back in 2014, which was good for a mid-sized billion-dollar startup but may be overkill for a one-person tiny startup.
I really think the key thing here is familiarity. K8s is a bit different, but certainly in OP's position I (personally!) would be more comfortable with an image for each component. Perhaps a machine image rather than docker, if each component is going to be on its own machine as described, but something at least semi-reproducible for sure.
When I'm working on something alone, and particularly if on and off and not for several hours every day I need to be able to come back to it in a sort of self-documented state that doesn't leave me scared to touch anything lest it crumble.
I think that one of the hidden points in there is that you do not really need a container to deploy python wsgi application, you need an venv and few system packages. Doing that by means of ansible playbook or even manually preinstalled system image that you just clone and then just only use Python packaging mechanisms is even somewhat simpler and faster than building container that works (ie. take a VM, poke into it until it works and then just clone it, deployment of your application is decoupled from the underlying OS)
A super interesting and refreshing read, especially since I am not very knowledgeable about web technology and most of the talk these days is about the latest fancy framework or database.
I am curious though, since I am using Google Cloud (App Engine in particular) for most of my company's modest backend needs: Would Google AE be able to handle all these backend requirements as well (but obviously without all the configuration and setup required)? Or asked another way: When is the point when you should move away from something easy and low-hassle such as GAE to something more advanced that requires a bit more manual configuration like setting up your own AWS servers?
Not trying to be critical, just honestly trying to learn from folks that know better than I.
The main idea of this article is to use what you already know and just get it done, rather than experimenting with new tools. The author already knew how to use most of these tools from a previous job. He stuck with the technology that he already knew, so that he could focus more on business aspects rather than new technology.
In that spirit, you should use the App Engine that you already know for as long as it seems to be working well for you. When you run into a problem that can't be solved in App Engine, that is the time to ask for advice on how to solve your problem.
Well, I'm super impressed. I wish I could do half of what this guy can do.
But he needs to be careful not to overdo it. It's fun and exciting to get all this tech up and running. But at some point, it becomes a drudge. And burnout is right around the corner.
I would say that if he can farm out as much as possible and focus on marketing and sales which are the drivers for most company's continued success. In a sense, he has by using the cloud but what he's doing is way too much for one person.
I used to be a laid back kind of guy and would get irritated when I was hurried and clearly there was no impending death. But now I understand that the limit lies within us. At some point, we all give up. There are those that take a long time and there are those that give up relatively fast but giving up is part of the process. So we are in a hurry to get as much done before we decide to stop what has not been successful. By putting so much burden upon your self you make it so much more likely that you will give up before you find success.
To all the people thinking “I couldn’t possibly do this myself” just look at the mention of UpWork towards the bottom. Looks like the author has brought in contractor help at some point.
This was really informative and delight to read. It's great to see developers making a go at the bizdev side and actually being really successful at it. Light on the heavy technical, light on the buzzwords, just the right amount of information to say, "here, if you even use half my stack you're well on the way to a viable product."
This is one of the most important post i’ve seen on HN so far.
it teaches you that you don’t need all the fancy stuffs, but you may need some of them. That you don’t have to shoot for the unicorn project, that you don’t have to build an A+ people team, etc.
It’s intelligent and gives all the interesting details to not give any kind of false impression.
Was interesting to read all the sort of "boring" back end pieces, then see that he went with half-server and half-client rendered React for the front end. Was expecting Angular or similar, given the pattern of the other picks.
I really like the idea of monolithic repos but can see some downsides when there is more than one person working on a project. It would be cool if there was a simplified way to have an entire business operate under source control.
> It would be cool if there was a simplified way to have an entire business operate under source control.
A lot of projects can and do apply CI tooling to achieve this. Every commit to a branch triggers a set of declarative deployment pipelines, simple. IIRC buzzword is "GitOps" if you want to find out more.
This interests me. Can you elaborate on what downsides you see? Even in a small team we're often working within the same repo at the same time without any issues.
The glaring issue would be permissions ie who can see what. Pull requests could get muddied up but that probably wouldn't be too much of a problem to overcome. Some foundational git protocols would have to be adjusted, like .gitignore.
I think it's a great way for start up to manage the business but as more people get hired the organizational complexity might be too much to bear.
An insight I've had recently is that the most efficient way to implement architectural changes that are not additive is to rebuild. Otherwise you're trending inexorably towards the lava layer and accumulating tech debt that you cannot track.
A useful direction to unpack is to define architecture. You cannot re-architect a building after it has been built, you must only demolish or rebuild elsewhere. This is why all architecture changes must be additive in nature, otherwise you're pulling the foundation out from under the building.
key missing info though: does it make money? I checked the site and it looks like a mix of ads (that are blocked of course) and a patreon with 5 supporters.
What are the pros and cons of charging a fee to transcribe someone else's audio content? Does ListenNotes need a lawyer to deal with contracts or problems related to original content creators?
Looks like they're taking an approach to transcribe first and then deal with it later. The transcription link has an FAQ asking them to contact them if they think they dont want others to transcribe their episode.
When you started working on this full time was there enough profit to pay yourself anything? How did you come to make the decision to work full time on it?
And does it make enough money to cover the time when it wasn't making money? As in: was the time spent bootstrapping worthwhile? The concept of a one-person company is extremely appealing in its simplicity and apparent lack of risk; however, the devil is in the details.
I'm going to go out on a limb here and confidently say he's doing fine. As he mentioned, he rented an expensive one person WeWork office in SF (when he doesn't even have to).
I think the assumption is that ListenNotes is his only source of income and that he isn't burning personal savings or the capital he has invested on non-mandatory expenses.
Granted those assumptions, you've got to get pretty far up Maslow's Hierarchy of Needs to hit "rent a WeWork"
I respectfully disagree. HN is very much about the -business- of tech. Telling us how you made your mousetrap is all well and good... Having us ask how many mice it has captured is absolutely relevant. Germane even.
Wonderful stuff! I've been trying to learn programming and able to code the CRUD apps for almost 6-7 years.
I've tried to learn Rails (Ditched learning Rails because JS framework are all the rage). Tried learning Flask/Django because it was considered easy. Ditched it too cause internet people said it's slow.
I tried learning Go, Phoenix and jumping between what's considered cool in last few years.
And here I am, no confidence to do a basic simple app. It's been an interesting journey with no luck because of constant chasing of 'Exciting' frameworks/Tools.
I agree with the general consensus pick one and stay with it for a few projects. If you can't pick one, just roll a die or anything. Maybe pick one a friend knows so you can collaborate in the future.
The differences between languages and frameworks won't matter very much unless you're joining a team with a preexisting stack or an edge case company/application that needs top-of-the-line everything.
Even if your app usage does scale beyond what your first version can deliver, you'll often get a bigger improvement by rewriting your app in the same stack using the new knowledge you've learned, than you would by rewriting the same logic in a newer stack.
I started along the same path as you. What i have been experiencing is Analysis Paralysis. Like the OP says, the trick is to commit to something that helps you from point A to Point B the fastest. And that for the time being atleast is RoR as is very opinionated and there are lots of humungous opensource, well maintained libraries floating around. And last but not the least, The Rails Tutorial actually bets you going to building something useful in no time. Good luck.!
I run a similar, maybe even more boring stack for my less-than-one-person company [PyDist](https://pydist.com):
- PostgreSQL database
- Nginx proxy in front of Django apps for UI and API servers (I use gunicorn instead of uWSGI though)
- Cron jobs which invoke django-admin commands to keep the PyPI mirror in sync
Perhaps the only place I'm any fancier than OP is that my deploy script is in Python, not shell, since any time I try to write a shell script with even slightly nontrivial logic it falls over and catches fire :)
What's your experience with gunicorn instead of uWSGI? I'm using haproxy + nginx + uWSGI but I'm wondering if gunicorn scales network more than uWSGI. My bottleneck isn't CPU, it's the amount of open connections uWSGI can handle at once.
Thanks for writing this article @webin. I'm about to launch a new startup myself and it is VERY boring tech. :p I'm running Rails with Sidekiq on Heroku, so I think I have you beat in the boring department. I do a lot of fancier stuff at work but I just don't need it for this product (at least not yet).
I am the only engineer but two non-technical friends (a designer and a lawyer[0]) make up the rest of the company.
Only question I can think of that I didn’t see an answer for is: is he running one postgres db, which is shared between the web and api services? Multiple services with only one db gets hairy fast with questions like: who owns the migrations? does the migration owning service have to restart the other service so the other service gets the new db column/table? etc
Unless the web also uses the API service to get its data. Really great article
The author can just run an Ansible job and recreate it instantly. It's a stateless ec2 node. If they wanted to be super duper fancy they could make an autoscaling group to destroy and recreate it if it went down. No need for a replica. This probably isn't a lose-100K$-every-5-minutes-of-downtime business.
I am all for simplicity, but if that results in a service outage whenever you deploy new code, apply a security patch or reboot your VM, you need to rethink the architecture.
Why if a minute downtime on deployment doesn't impact revenue significantly ?
The frontend can even have some exponential cool down on requests when the backend is down and the users who are online in that one minute window will suffer just notice it being a bit slower.
He even mentioned his uptime in last years in the post.
Interesting, there seem to be lots of opinions about the chosen stack. But as a designer, I have no idea what to make of it.
Recently I rode the Figma API release hype train, and I made a plugin which is quite successful. Almost 10k active installs. It is basically a collection of the most popular viewports and their market share. I also have a server where I store the data. Every other day I run a script which updates the market share and that is about it. To summarize it:
- I have a client (react app written in typescript) which has a very simple "caching" mechanism (if you asked the server for new data more then a day ago, ask again) and which shows the data and nothing else.
- And I have a server (express js) running on Heroku (where I also have the Postgres DB). The server has a basic REST API and very default admin interface. But most of the time the server is not doing anything.
It was something I was able to put together quite fast, but now reading all the comments I'm thinking whether it isn't over-engineered and whether I should go with serverless and possibly reduce the costs.
Your mileage may vary but there’s a real opportunity for the latest technologies to save you work and headache.
My own one-man startup Trunk[0] is very infrastructure heavy so I’m super thankful for technologies like Docker. You don’t have to go full-blown Kubernetes but there are various small wins you can still have. Need to upgrade a piece of your stack? Just build a new container a deploy it! Need to bring up all your services in development? `docker-compose up`! And with Docker Swarm, it’s super easy to scale up background job and application processes across multiple cloud instances. I can’t imagine doing this without Docker.
When getting a business off the ground, it’s extremely important you do customer development and not new technology development. When running a business however, new technology can become a competitive advantage and help you move faster. Just make sure it’s really doing that.
These success stories always pain me a bit. I tried for some time to get my own project going based on personal interest, but it never went anywhere. I have people visit the site but retention and use is a problem. https://imetatroll.com
- golang, gopherjs, bootstrap, DO, and kubernetes.
I think this looks cool, and I feel your pain on the retention/use problem as I have also made a game that requires multiple people to use to create value.
I never found a way to promote it to groups of people instead of individuals. Even in a meetups/expo setting it's hard to get critical mass and momentum.
Security concerns are always conspicuously lacking from this type of posts and discussions. If you’re a solo dev looking to start a project, please don’t take OP’s stack as a positive example. Use managed services whenever possible, they will at least keep you patched and simplify intrusion detection when configured correctly.
I've built Libr (https://librapp.com), a full social networking platform designed to fill the void Tumblr left behind.
The hosting is serverless for both the front end assets and back end no servers to maintain and infinitely scalable.
Libr has a front end progressive web app built with VueJS hosted on S3 with CloudFlare in front.
The back end API is hosted on Lambda. By using serverless framework things are portable. I could easily migrate to another serverless provider or even host my own.
Both the front and back end use the same programming language, TypeScript.
The database is Elasticsearch, just like WordPress.com (they don't use MySQL for most things).
Each month, I receive a nice little invoice from AWS for under $1 for the hosting. So far CloudFlare is free for me.
I built everything by myself, with no team. I have had input from Libr users on feature requests and UI improvements.
I wish I could've known more practical info about starting a company before I quit my day job, e.g., how much for insurance, what company credit card to use, how to pay tax, where to find lawyers... Online articles / advices are mostly focused on big picture or very abstract concepts or fortune cookie type words :(
At this point, I would add Docker (without Kubernetes) to the "boring" technologies that simplify your life. Having managed my own "server farm" of 20 machines on hetzner, with a very small startup, I found that abstracting away the underlying OS removed a lot of friction.
I've found the tradeoff is in favor of using ECS, Kubernetes or something similar. The docs aren't too bad now. It is great to be able to build/deploy a docker image and not worry about how it gets out there, and what might go wrong with that system.
> Basically, I have a wrapper script deploy.sh that is run on macOS:
I do the same thing on Linux.
build.sh, deploy.sh.
But, I also use a run.sh which runs tasks that I may not remember to run if I come back to software after a while on a certain machine.
Like 'git pull' or 'bundle install'. Then ./dev-setup.sh or whatever for starting up tasks.
I use multiple machines and having these two simple commands saves me so much frustration.
You sit down to began work. You just run ./run.sh and it will setup a dev instance for you. No sudden alerts that your gem is out of date... or worse... no warnings at all and hard to diagnose sudden bugs that steals half a day from you.
I've found trying to figure out complicated build tools to mostly be a waste of time unless you really need them. It also encourages you to not do things that would require very costly builds.
the key for me is a backend-as-a-service platform that i can reuse over and over. i used to be mainly a backend developer, but for more than 5 years now i have barely touched the backend code because it was designed to be reusable.
i build SAP applications now because they make it easy to work with a reusable backend.
for the rest of my system, i use basic LXC containers. no docker, or other container management system.
deployment consists of setting up an instance of the backend, and generate the frontend as static files that can be hosted whereever.
I'm surprised no one has mentioned Heroku yet. I'm a one man business too, and 90% of the details in this post I don't even have to worry about. Sure I pay a pretty penny for it - at least a thousand a month - but it just works. Rails and all of its beauties, postgres, redis, sidekiq, sendgrid, twilio, Scout, Papertrail, and that's about it. Looking to add AppOptics soon for business KPI / APM metrics.
I'm impressed with the profit margins. It looks like one of the main sources of revenue is transcription. From what I can tell the price seems to be about $4/hr.
OP said they are AWS. If they're using Amazon Transcribe, the cost for that is $1.44/hr.
A 150%+ profit margin is awesome! Well for that one piece of the service. Obviously at least some of the cost of the website and database, etc must be included, but still. Pretty amazing.
I'm guessing the $4/hr price estimation is based on an average of the prices ListenNotes actually charges to transcribe a podcast, as shown on ListenNotes.com for various individual episodes.
Oh wow. This is scaringly close to how we run geocod.io - right down to the ansible provisioning wrapper that I put together :)
> ./provision
provision usage:
./provision environment role [hostname]
This script will provision the given role in the specified environment using Ansible
If a hostname is specified, provisioning will be limited to that specific server
I wouldn't call that boring, there's still a lot of new technology being used in that stack. I'd also recommend some minor improvements to the workflow (e.g. don't do development work on the master branch) that are easy to achieve and provide big benefits. Also - no mention of backups or DR-planning -- I'd be interested to know what's being used in this area?
As soon as he has a bigger team of developers, some of his technology choices might cause trouble. Especially not having a build server will cause chaos very quickly, because nobody will know, who has deployed when and what. A good deployment pipeline with a good test battery using a boring build server like Jenkins can help a lot here.
Okay that guy is just showing off, but rightfully, this is damn impressive. Even if some of that is offloaded to contractors, he still needs to understand most of it.
That's a proper full stack developer with a business mindset as well. Hope I'll improve my backend / devops skill to that level at some point.
Very inspiring article. And thanks for sharing a detailed tech stack write up. Very inspiring for me as I am also a single person running a tech news aggregator website but probably even more boring setup on AWS (php MySQL Apache and some python ) embit.ca , running it alone but never lonely.
Well, on frontend he uses React/Redux/Webpack, which is more of trendy, latest/greatest. If he used Django templates + jQuery, that would have been staid/boring tech. Great post though, aspirational for those of us who wish to found their own startup one day.
Great post - I'm running almost the same exact thing - Flask instead of Django, Saltstack instead of Ansible, rq instead of celery - supervisord, postgres, redis, ubuntu, nginx, aws (actually multicloud, BigQuery for data).
Very inspiring. As a coding newbie / wannabe entrepreneur, I will need some time to understand what each part of your technology does though. I will start using Listen Notes later today. Keep up the good work!
I'd love to know how you're running Django and React together. I've been trying to figure out how to make that combo work in a mono-repo, and I'm definitely missing something. Any advice?
I just watched 8 hours of Django videos yesterday, and 4 hours of that was a Django + React tutorial. It covers in great detail the CRU from a CRUD, but you'll need additional videos to cover deployment on elastic beanstalk or ec2+elb, etc. https://www.youtube.com/watch?v=AHhQRHE8IR8
Basically his tutorial was to put the react project inside the django project, and depending on which parts you're modifying and how your testing, he has a special static collection script that builds the react portion and copies the static files up into the Django parent project folders.
I'm also struggling a lot with django, react and the whole asset pipeline. On the other hand, frameworks like rails and laravel have it all figured out for you.
Listen Notes is a nice service. I don't quite understand how it works -- do podcasts pay to be included in search results? It's a nice thing for the listener, that is for sure.
As someone still in school, this type of article -- though inspiring-- kind of scares me, to be honest. I don't think I could do any one of the things mentioned in this article.
I couldn't do all these things when I was in school :) I worked in companies for a few years and learned some engineering practices. Then I had basic skills to prototype my own side projects. Then after working on many silly side projects, I started Listen Notes.
And initially, Listen Notes was running on 3 tiny DigitalOcean servers ($5/month each?). I logged in each server to git pull to "deploy to production". Then I added things little by little, day by day. It's a process. The key is to get started. People say that showing up is 80% (or whatever percentage) of success. I think this is very true. Just get started and you'll figure out things along the way.
Thanks for the info. It's an interesting set of tools today, but it's helpful to hear that it has evolved to that point in terms of automation and infrastructure.
The first version of a web service can be as simple as flask app which you run in a screen session somewhere. Better to start somewhere than get overwhelmed and never do the thing at all.
Exactly what I'd like to tell younger devs and students. You build smaller projects on the side for a bit to familiarize yourself with things until you're ready to start something or something comes along by way of the side projects!
Thanks Alan(?). I haven’t gone too far with Django. I can see what you’re saying about being seasoned. Flask clicked for me quickly but everything just made sense, ORM, Jinja, modules etc.
As a senior dev: it will take years of experience and constant learning to get to this point, but it is attainable. You don't have to be a master of each part of the stack and each tech within it - you just need to be able to do enough, and solve the problems you face. You can build a professional SaaS product with a simpler stack as well.
You take a project like this one step at a time. Some bits of it are relatively easy - setting up a few postgres servers doesn't take much knowledge. ElasticSearch is a little more obscure, but for the most part, things like this are running a few commands, and setting up a few config files with the help of docs and google. Same for Redis, nginx... etc. Which isn't to diminish devops - you can dive deep into each of these configurations and develop pretty complex setups, but by the time you actually need to you hope to be making enough money to pay someone else to do it.
You won't get everything perfect all the time. You'll have to revisit parts of the stack and tweak them. But you can take it a day at a time and do what you need to do.
I wonder when developers are working for themselves / very early stage, if one automatically becomes more conservative?
If someone else is paying for your time, it's nice to experiment and grow personally. When it's your own buck, the focus is on pragmatic shipping and getting revenue coming in.
@wenbin - What would also be helpful is a P&L report on all of these expenses - as that will also tell us a great story.. and it would make a nice Part Deux ;-)
Having experience in both realms, it seems kind of interesting that Docker is considered overengineering while React + Redux + Webpack + ES is considered natural and simple. I guess 50% of "overengineering" is really just "I'm not familiar or comfortable with ths".
I listened to an interview with DHH the other day and he was calling out that one of the advantages of frameworks over libraries is that everything comes wired up ready for production instead of you spending all your time writing glue code and arguing about conventions.
I'm still not exactly certain where I fall on this topic. What I do know is that I don't like frameworks that conceal the plumbing and leave you with declarative bits that require memorization. Lack of discoverability is a huge barrier to mastery. The best code invites you to determine why something is happening.
What I've been thinking about lately that this article drew out for me again was that it's a shame that so many tools and libraries come not ready for production by default.
It would be nice to have some curated base file sets where insecure defaults were overridden, and all of the metrics and logging logic were wired up. You get the turn-key solution but you still have code that is more discoverable, and you can veto a few choices without too much effort.
Technically, you don't know that since we don't know who Satoshi Nakamoto is. Satoshi Nakamoto could really be 10 people and you nor I, would not know.
When my website (https://www.aedaily.net) has a million of record, I had migrated Postgres to Mongodb because performance issues.
I'm using Django template to easy maintain, development and SEO.
As a software SaaS CISO, who also pentests and determines partner risk - I take the approach of not sharing such in depth details. Articles like this are fantastic fingerprinting recon for those that look to compromise sites.
That's right, any pentester worth anything will know the stack used in a few seconds by looking at cookies or even sometimes just by the login page's url. For ex: different frameworks have different session and csrftoken naming, Rails and Django have recognizable url conventions, and there's always default error pages that usually give away the framework used.
No - they won't. If you have a very simple front end stack, and application stack or infrastructure sure. But if I'm needing to traverse networks, or only directly get to a database - that's different than some silly nmap script kiddy scan.
Remember it is often easier to penetrate around the gates where everyone is looking (some app stack + OWASP top 10) to instead focus getting inside a network (your dev's laptop, vpn connection, social engineered access, malware to your CEO or sales team, Wi-Fi connection to intercept the VPN tunnels, etc). Or i'm looking for holes in Docker versions to root, Kubernetes flaws, virtual machine dependencies, how many microservices layers do I have to deal with, etc etc.
Sure - telling me whether you have an api.<domain>.com doesn't matter. Anyone can scan and find that. But, if I know your database names (from a screenshot) and your hosting provider, I know that once I'm past a bastion host, or on your VPN connection - I don't have to wait to sniff or hope you connect to datasources. I now have an informed opinion on where to go.
I've often worried about that; in fact its really kept me from blogging about our infrastructure at all. Am I too paranoid? I've often thought if I were to do so that I'd set up a honeypot; but who has the time for such games?!
This is just a big ad for his website with no in-depth knowledge or insights provided. Literally just a list of tech someone uses and 4 or 5 links to his website. Is this what HN has become? I remember the content upvoted on this site being much better a couple years ago.
It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.
Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.