The whole point of LLM-based code execution is, well, I can just type in any old language it understands and it ought to figure out what I mean!
A "skill" for searching a pdf could be :
* "You can search PDFs. The code is in /lib/pdf.py"
or it could be:
* "Here's a pile of libraries, figure out which you want to use for stuff"
or it could be:
* "Feel free to generate code (in any executable programming language) on the fly when you want to search a PDF."
or it could be:
* "Solve this problem <x>" and the LLM sees a pile of PDFs in the problem and decides to invent a parser.
or any other nearly infinite way of trying to get a non-deterministic LLM to do a thing you want it to do.
At some level, this is all the same. At least, it rounds to the same in a sort of kinda "Big O" order-of-magnitude comparison.
On the other hand, I also agree, but I can definitely see present value in trying to standardize it because humans want to see what is going on (see: JSON - it's highly desirable for programmers to be able to look at a string representation of data than send opaque binary over the wire, even though to a computer binary is gonna be a lot faster).
There is probably an argument, too, for optimization of context windows and tokens burned and all that kinda jazz. `O(n)` is the same as `O(10*n)` (where n is tokens burned or $$$ per second or context window size) and that doesn't matter in theory but certainly does in practice when you're the one paying the bill or you fill up the context window and get nonsense.
So if this is a _thoughtful_ standard that takes that kinda stuff into account then, well, great! It gives a benchmark we can improve and iterate upon.
With some hypothetical super LLM that has a nearly infinite context window and a cost/tok of nearly zero and throughput nearing infinity, you can just say "solve my problem" and it will (eventually) do it. But for now, I can squint and see how this might be helpful.
The lesson from “big software projects are still failing” isn’t that we need better methodologies, better project management, or stricter controls. The lesson is "don't do big software projects".
Software is not the same as building in the physical world where we get economies of scale.
Building 1,000 bridges will make the cost of the next incremental bridge cheaper due to a zillion factors, even if Bridge #1 is built from sticks (we'll learn standards, stable, fundamental engineering principles, predicable failure modes, etc.) we'll eventually reach a stable, repeatable, scalable approach to build bridges. They will very rarely (in modernity) catastrophically fail (yes, Tacoma Narrows happened but in properly functioning societies it's rare.)
Nobody will say "I want to build a bridge upside-down, out of paper clips and can withstand a 747 driving over it". Because that's physically impossible. But nothing's impossible in software.
Software isn't scalable in this way. It's not scalable because it doesn't have hard constraints (like the laws of physics) - so anything goes and can be in scope; and since writing and integrating large amounts of code is a communication exercise, suffers from diseconomies of scale.
Customers want the software to do exactly what they want and - within reason - no laws of physics are violated if you move a button or implement some business process.
Because everyone wants to keep working the way they want to work, no software project (even if it sounds the same) is the same. Your company's bespoke accounting software will be different than mine, even if we are direct competitors in the same market. Our business processes are different, org structures are different, sales processes are different, etc.. So they all build different accounting software, even if the fundamentals (GaaP, double-entry bookkeeping, etc.) are shared.
It's also the same reason why enterprise software sucks - do you think that a startup building expense management starts off being a giant mess of garbage? No! IT starts off simple and clean and beautiful because their initial customer base (startups) are beggars and cannot be choosers, so they adapt their process to the tool. But then larger companies come along with dissimilar requirements and, Expense Management SaaS Co. wins that deal by changing the product to work with whatever oddball requirements they have, and so on, until the product essentially is a bunch of config options and workflows that you have to build yourself.
(Interestingly, I think these products become asymptotically stuck - any feature you add or remove will make some of your customers happy and some of your customers mad, so the product can never get "better" globally).
We can have all the retrospectives and learnings we want but the goal - "Build big software" - is intractable, and as long as we keep trying to do that, we will inevitably fail. This is not a systems problem that we can fix.
The lesson is: "never build big software".
(Small software is stuff like Bezos' two pizza team w/APIs etc. - many small things make a big thing)
I agree with you on "don't do big software project" Specially do not fast scale them out to hundreds of people. You have to scale them more organically ensuring that every person added is a net gain. They think that adding more people will reduce the time.
I am surprised on the lack of creativity when doing these projects. Why don't they start 5 small projects building the same thing and let them work for a year. At the end of the year you cancel one of the projects, increasing the funding in the other four. You can do that every year based on the results. It may look like a waste but it will significantly increase your chances of succeeding.
>Building 1,000 bridges will make the cost of the next incremental bridge cheaper due to a zillion factors, even if Bridge #1 is built from sticks (we'll learn standards, stable, fundamental engineering principles, predicable failure modes, etc.) we'll eventually reach a stable, repeatable, scalable approach to build bridges. They will very rarely (in modernity) catastrophically fail (yes, Tacoma Narrows happened but in properly functioning societies it's rare.)
Build 1000 JSON parsers and tell me if the next one isn't cheaper to develop with "(we'll learn standards, stable, fundamental engineering principles, predicable failure modes, etc.)"
>Software isn't scalable in this way. It's not scalable because it doesn't have hard constraints (like the laws of physics)
Uh, maybe fewer but none is way to far. Get 2 billion integer operations per second out of a 286, the 500 mile email, big data storage, etc. Physical limits are everywhere.
>It's also the same reason why enterprise software sucks.
The reason enterprise software sucks is because the lack of introspection and learning from the garbage that went before.
What strikes me immediately are the vibrant colors of the houses.
Walk through most any suburban American neighborhood and you'll primarily see neutral shades of white, gray, beige, or the occasional muted blues and greens. Sometimes someone will be daring and paint their house in a deep, dark blue or purple (or even black) but that feels relatively rare.
If near the ocean, typical "seaside pastels" come into view.
What's the backstory to the Faroes' colors? Are they set by some local entity/government? Left up to the homeowners? Was there a push to make them colorful? Do the locals have a particular eye for color composition? Did someone help them?
Why are American homes so bland and the Faroes' so delightfully colorful?
My first thought was that given the rather inclement weather perhaps having a vibrantly colorful house may have historically helped to easily identify one's particular domicile during times of poor visibility.
Certainly a huge part of the color choice in the US is to increase sales. A neutral color is just easier to sell. In the Faroes, this probably doesn't matter. Just pulling a guess out of my rear.
I agree - microservices are a technical solution to a people problem. Stevey's seminal "Platforms Rant" (https://gist.github.com/chitchcock/1281611) touches on this - the reason why Dread Pirate Bezos mandated services was not because Kubernetes was cool[1], but because their teams were too interconnected, moving too slowly, and Conway's law was getting in the way.
Splitting into services siloed each team and allowed them to move independently and by side effect, faster. Not due to inherent properties of (micro) services but because one goes faster by removing the things that slow you down.
As a startup, you do not have this problem. You likely will _never_ have this problem as your default future state is 'dead'.
Do the simplest thing that can possibly work - build a monolith using tools you know that give you the ability to predictably, rapidly iterate on the product.
After you hit some semblance of product/market fit and need to scale, you can do that. Scaling is a solved problem. Premature scaling is not.
[1. This is a joke. Kubernetes wasn't even a thought in Google's eye at this point in history]*
> the reason why Dread Pirate Bezos mandated services was not because Kubernetes was cool[1], but because their teams were too interconnected, moving too slowly, and Conway's law was getting in the way.
Not quite. Amazon's problem was that they were experiencing too much impedance between teams, and some teams were even siloing themselves to the extent they were creating problems for everyone around them. Bezos' diktat was intended to break through a bunch of petty office politics bullshit that was dragging down the company and preventing teams from delivering their work. The diktat boiled down to basically ordering everyone to grant access to the service they owned and provided to external teams that need it, no exception, and would be held liable if they failed to provide it, intentionally or not
Your three superpowers as a solo founder need to be:
1) Deep expertise and network with potential customers
2) Ability to empathize and connect with your customers and sell the thing
3) Ability to build some sort of MVP
The deep expertise and empathy will allow you to hone in on the problem you know your customers will face, and so you can narrow down the "paradox of choice" of different features/products you can build. It'll give you a much better starting point for experimentation and iteration. Start small. Talk to these folks. Get people to validate your idea. If you don't have an existing network where you can talk to 30-50 customers (100 is better!), this will be a problem.
The empathy and salespersonship will allow you to get folks to give you feedback and/or pre-sell the thing. Maybe do consulting for them to earn revenue and testimonials. If you can't sell this, you're going to have a hard time.
Finally, you need to be able to build something that delivers value to your customers. You don't have to be the world's greatest programmer (actually, if you were that might hurt you more than it helps!) but you do need some programming chops. Maybe it's automation around an existing process (a chatbot that does something small). Or even a spreadsheet. Maybe it's a full-blown MVP. Either way, you don't have the revenue to pay a developer, and sharing context with someone that you can afford is likely very very difficult.
If you don't have these things, this will be really, really tough. If you do, it will still be very tough, but you have a much better chance of being successful.
Find a network of solopreneurs - either something local to you (where you can meet up periodically) or an online group. This will be invaluable as you run into challenges they solved, and then you can pay it forward for the people that will walk your path later. And, having a place to vent with empathetic folk will help keep you sane.
If you need any help, I'm happy to share my experiences solo-bootstrapping my company to 20+ people. Just email me matt [dot] rogish [at] gmail
Always always always use a payroll provider. If possible (size permitting) use a PEO (JustWorks, TriNet, etc) to take care of payroll taxes and state/local unemployment registration/withholding etc. (especially if you are distributed and you have folks in many states). Getting this wrong can destroy your company, and PEOs are super cheap by comparison!
Absolutely agree with this. They have software that accurately takes care of so many fine details and at such a reasonable per-employee price point that you would have to be nuts not to use one as a small company. In fact it makes me believe Bannon just didn't give it much thought.
I agree. We moved from NYC to suburban Philadelphia (walk score of almost zero). We both work from home, which is great. But the house has been one project after another, and although there are ebbs and flows, there's likely always something going on. We're financially better off (our house is like 1/3 the price of our small 2 bdr rent in LIC) but the never-ending trickle of work is mentally taxing.
We needed to replace our washing machine when we bought the house, so I did the research and got the best front-loader we could afford. Turns out, due to $reasons, it vibrates throughout the whole house (it's on the second floor) and although it's working fine, every time we do the laundry we shudder at the annoyance. Now, we eventually will have to settle for a lower-performing top loader but I'm still not 100% certain that it won't cause the same problem, so we feel stuck. Keep the good, but frustrating, washer, or take a risk that another almost thousand dollar washer will have the same problem. Outsourcing these decisions and annoyances to a landlord is appealing.
Fighting entropy is a great way to put it - we had things come up that resulted in our inability to tend to the garden, and in a month, it's overwhelmed with weeds. That's my weekend project. Could we pay someone to clear it? Sorta. Service providers don't like (for obvious reasons) small projects, so nobody will return our calls when we say "It's like 2-3 hours of weeding". Could we find someone (say, a college student or something?) to do it? Probably, but it'd be almost more work to find and vet someone to do the work than it is to just do it ourselves. And, there goes a weekend. A weekend that, if we were still in the City, would be spent doing anything else.
I wouldn't trade it for almost anything, but it's not clearly the best solution for everyone. I would totally pay the equivalent of a "condo fee" for someone to manage all this nonsense.
Turns out, due to $reasons, it vibrates throughout the whole house (it's on the second floor) and although it's working fine, every time we do the laundry we shudder at the annoyance
This is why washing machines are usually on the ground floor in UK homes - usually in the kitchen, where they're close to the plumbing, despite there being very little overlap between food preparation and washing clothes.
For a B2B SaaS company, the easiest/most likely[1] algorithm to succeed[2]:
1) Be embedded in the industry for a while
2) Make lots of connections, build credibility
3) Build SaaS app to solve key pain point you experienced in #1
4) Sell to the folks you know from #2
5) For bonus points/de-risking: find 25 potential customers (from #2) and reach out to them and validate this idea (Jobs-to-be-Done). Get a handful of them to commit, even verbally, to buy this when you've got an MVP built.
[1] Clearly this is not the only way to be successful, but "I have a random idea lemme build it" is a great way to be not successful
[2] Succeed = your business that makes enough revenue to support you and a reasonable lifestyle, equating (and/or eventually surpassing) what you would typically make at a W2 gig, from a diversity of customers and not trading your personal time for money.
This is exactly the recipe I used and sold a company for $10m. Also, I am a absolutely terrible programmer and v1 of the product, with which this recipe was executed, was full of copy pasted code, unhashed passwords, all of the hallmarks of terrible programming. I got to $100,000 revenue before a friend of mine joined who actually knew how to program and rewrote the whole thing (literally zero lines of my original code were preserved).
I’m not the poster here but I’ve been involved with the sale of a few businesses like this and I consult for a VC. I’ll answer a few of these.
I’ve seen owners (either single or partners) who own between 5% and 100% of the business when they sell it. Unfortunately, most of them seem to own between 5 - 35%.
Most of the sales I’ve been involved with are the company trying to find a buyer. However, occasionally a VC will flat out ask if the company is for sale. Though it’s probably 10 to 1 in my experience.
There’s usually some level of negotiation. There is a “SAAS multiplier”. Right now the VC I consult for looked at about 3 - 5 times EBITDA. This gives you a healthy negotiation range.
People should absolutely consult an accountant and an attorney when figuring out what to do with the money they make. Often if you handle it right you can pay significantly fewer taxes. Taking stock or equity is a good way to handle reduction of those tax burdens.
I’ve seen people celebrate by buying multiple very expensive cars. A house on the beach in Hawaii. Huge trips. I’ve seen people blow huge amounts of money very quickly. The fastest was two guys who blew through $3,000,000 each in 6 months. It was stupid.
Most of the sales i have been involved in kept the former owners in a working capacity at the company.
I hope this helps a bit. Obviously it’s just my observations.
I made just over $1m because we raised a bunch of money for growth that didn’t pan out. Because LOL California the money went straight into a house. I still have a mortgage and a day job.
Bigger lesson is to buy a house as soon as you can. I’ve made more money on paper living in this house than building the company.
I kind of needed to raise the money. The wheels were falling off the bus because the software was so bad and it needed to be professionally written. I should have raised less and sold sooner though.
If you're at all interested in adding your story to this list or future lists, let me know! Sounds like something we could all learn from. I'm courtland@indiehackers.com
When I first saw indiehackers, I was in love with it. The execution was fantastic. You did a great job.
Then it got bought, and changed. Now it's forum-first, interviews second, and half of them are sort of locked.
Why do you now have to sign up for a forum to view the older product interviews? It's super annoying, so I just stopped reading. It also seems detrimental to the people who gave interviews early, they wanted press, rather than being hidden behind a sign up thing.
Is there any interest in reverting from this pinterest-style login-wall, or is that just too costly?
If this sounds blunt, it's only because I'm disappointed that a site a loved became less fun to use.
Walling off the content directories was an experiment to boost community membership signup, as community members are far more active than anonymous visitors. It's worked — people have joined the community at a much higher rate — but the downstream results haven't been significant enough for this to really be the backbone of our growth strategy. I will likely revert it soon in favor of other approaches, for example, creating search engine friendly evergreen content like this article.
Slightly off-topic, but what happened to indiehackers? I liked the page more before the redesign/stripe-takeover.
The page was more clearly arranged and you could browse it without being logged in or having an account. There is also this ridiculous "stripe-verified" badge for businesses doing business with Stripe now, which is not that interesting for indie hackers I guess.
It also seems the interviews are not that important anymore, but being some kind of community is - but I don't think that people want that, because we have that already here or at reddit - the nice thing were the interviews.
>> you could browse it without being logged in or having an account.
That's a fair point I hear quite a lot. Not sure what the reasoning is there (assuming it is the case).
>> It also seems the interviews are not that important anymore, but being some kind of community is - but I don't think that people want that, because we have that already here or at reddit - the nice thing were the interviews.
Have to really strongly disagree on this point... The IH community is - without a shred of doubt in my mind - the single most impactful thing Courtland has built at Indie Hackers. Happy to believe that you don't want that, but there are a lot of founders and lurkers on the IH forum who really do want it...
is closest to the old layout where each block linked to the founder interviews. I basically wrote the site off until today because it looked like the interviews had been walled off.
I read this story exactly the opposite: it doesn’t have to be perfect at the start. You just build something people want, and then hire a team to improve the back end (without destroying what people wanted it for in the first place).
Major companies have had security issues (such as Adobe) but that doesn’t make them a fraud.
FWIW, at that time Adobe was already properly handling the password - what leaked was an old backup. Where passwords were hashed, just not properly.
Adobe did mess up on that one - it's just not on the same level, not even close. The main thing that makes it worse was that Adobe has a lot of customer data (likely unlike this guy, who probably didn't have many customers)
I didn’t have any idea what I was doing. When my cofounder arrived and looked at the code base... he looked like he was going to puke. Took him less than 5 minutes to decide that there wasn’t even a line worth keeping.
Agreed, but there is a slight twist to that I have seen be even more effective.
1) Consult in the industry as a contract developer at X/hour rate.
2) When you find a problem that they're facing that you might be able to turn into a business, offer them 0.75X/hour while you work on it in exchange for the right to commercialize it.
Obviously this doesn't work for everything, but it's a non-obvious way to get paid while fixing a real problem and build a business.
2.b Be independent contractor. Carefully work on side-biz on your own time. Have good documentation and git-log in case someone at the client ends up caring when you worked on it (zero risk if it's not core biz for them and they aren't assholes). Don't tell anyone what you're working. Don't use proprietary data in your product. Profit
Again, every situation is different. But the benefit of bringing the client in is that they can act as your first reference client (the hardest to get), and that it's not job+sidebusiness, but a hybrid so your time is more efficiently spent.
1 through 3 is 100% correct in my experience. I left my job recently and after a short break I called 3 friends from the industry side and 3 friends from the customers-of-that-industry side and said "if I do this will you pay me?"
This has nothing to do with comming up with idea like the title suggests. And it's because having ideas is overated. You find good ideas everywhere, all the time. the execution matters the most, which is part of what you describe.
It's possible they disabled the localhost check at some point.
Edit: It does now, after Travis folk fixed it. :D
And, Rails (which I assume they're using) typically loads DB credentials from a `database.yml` file for a particular `RAILS_ENV` (local dev, local automated testing, prod). By setting the `DATABASE_URL` env var, they are overriding that (this is fine/expected behavior for app deployment as far as Rails is concerned; it's comparatively less common for localdev). So that bypassed the `RAILS_ENV=prod` check that might also have caught this (e.g. `RAILS_ENV` was undefined or `development`).
So I'd really have loved it if they dug into some of the UX factors to this issue:
* Why do they allow remote access to their production database? (Is it too hard to get a local database copy? "For debugging purposes"? Why was the eng in prod the day before? Was it unintentional? Should we revisit those assumptions? Should we resolve whatever issue that caused us to shortcut by allowing remote, direct prod db access?)
Why, for localdev, they override database.yml and use env vars (which I've found is more cumbersome to use and not as common). Yeah, in production you should use RAILS_ENV/DATABASE_URL/etc. - so are they attempting to have prod parity? Why or why not?
* Why are folks routinely logging in (for debugging purposes) with a DB user that is, effectively, root? I bet that user can `drop table` too. Should folks have a limited access account and then jump through a hoop or two for root?
It sounds like they want to "debug" prod by running some local rails tools (rails c?) with DATABASE_URL set to the prod db. Is that the "best" way to do it? heroku etc. actually open a rails console in the environment and not locally.
https://www.ReactiveOps.com | Sr Site Reliability Engineer (AWS/GKE Kubernetes) | Full-Time; 155-160k DoE; 0.01% equity | Remote, Right-to-work-in USA
ReactiveOps is a DevOps consulting and services company, focused on AWS/GKE. We setup, maintain, and operate Kubernetes clusters for our clients, setup CI/CD, migrate their apps into Kube, etc., in addition to day-to-day cloudOps works. We are in Slack with them and act like their "outsourced, in-house Ops team". Our goal is to exceed the capabilities and care of an in-house Ops organization.
We are a completely distributed team of 16 highly motivated folks, and are 100% bootstrapped and profitable.
I spoke to you at length and then your cofounder at length. Then it turns out that you don't actually have any immediate need to fill the role but you "might" have a need in the next 30 to 90 days. I pretty much gathered that you basically subcontract.
I'm sorry you felt your time was wasted; we do not aim to do that at any point in the process (it wastes our time, too! :D). We are a kubernetes consulting and DevOps-as-a-Service shop, and some amount of our demand's final materialization is unpredictable. We take pains to mention that in the beginning but, if we didn't, that's on us and I'll make sure we don't miss that again - thank you for bringing that to my attention.
I don't know your situation, but it's highly likely we had a significant influx of demand that suddenly softened, and we had to back-off on the hiring. Or, perhaps also likely, we hired someone that more closely matched the position and needed to pause the search (we have 3 people starting on Monday, Feb 5, for example; we've hit our quota of less experienced Kube experts and have re-focused on people with extensive cloud production kube experience).
As a profitable but bootstrapped firm that has (yet!) to lay off people due to underwork, we strongly bias against pre-emptive hiring.
I wish you the best of luck in your career, and if you are still looking, in your search.
>"I don't know your situation, but it's highly likely we had a significant influx of demand that suddenly softened, and we had to back-off on the hiring."
Except that I replied in response to a "who's hiring" thread and the interviews followed very close to my responding. So why would you even be posting that you are hiring if you had "demand that suddenly softened"?
I went through a very lengthy interview process with this company, and made it to the final stage. Had great conversations with everyone at every step and ultimately was turned away with no explanation whatsoever.
That being said, a lot of the folks I spoke with seemed pretty sharp. YMMV.
Although we strive to hire everyone who reaches the final stages (it's super time consuming for everyone, you and the team!), ultimately we have to turn away people who are awesome but aren't a perfect fit (at our teeny-tiny size back in [time redacted] when you interviewed, we were even pickier than we are now; I wouldn't read too much into our decision to not move forward).
We've made a lot of changes in our process since you spoke with us and I hope we're more communicative - to the best of our ability - in our process. I wish you the best of luck in your future endeavors!
I don't think it had anything to do with you. If you notice they always say they're "hiring" on these threads. However they don't necessarily have any new "client" to subcontract out to someone. They don't seem to have any problem wasting people's time though.
The whole point of LLM-based code execution is, well, I can just type in any old language it understands and it ought to figure out what I mean!
A "skill" for searching a pdf could be :
* "You can search PDFs. The code is in /lib/pdf.py"
or it could be:
* "Here's a pile of libraries, figure out which you want to use for stuff"
or it could be:
* "Feel free to generate code (in any executable programming language) on the fly when you want to search a PDF."
or it could be:
* "Solve this problem <x>" and the LLM sees a pile of PDFs in the problem and decides to invent a parser.
or any other nearly infinite way of trying to get a non-deterministic LLM to do a thing you want it to do.
At some level, this is all the same. At least, it rounds to the same in a sort of kinda "Big O" order-of-magnitude comparison.
On the other hand, I also agree, but I can definitely see present value in trying to standardize it because humans want to see what is going on (see: JSON - it's highly desirable for programmers to be able to look at a string representation of data than send opaque binary over the wire, even though to a computer binary is gonna be a lot faster).
There is probably an argument, too, for optimization of context windows and tokens burned and all that kinda jazz. `O(n)` is the same as `O(10*n)` (where n is tokens burned or $$$ per second or context window size) and that doesn't matter in theory but certainly does in practice when you're the one paying the bill or you fill up the context window and get nonsense.
So if this is a _thoughtful_ standard that takes that kinda stuff into account then, well, great! It gives a benchmark we can improve and iterate upon.
With some hypothetical super LLM that has a nearly infinite context window and a cost/tok of nearly zero and throughput nearing infinity, you can just say "solve my problem" and it will (eventually) do it. But for now, I can squint and see how this might be helpful.
reply