Jugurtha

Dusting off some old replies. The TL;DR is: reduce information asymmetry, expose thought processes and align (everyone knows what to do, what not to do, why, and how we got there). People should send in pull requests to your thought processes. They should be able to take decisions based on their model of your thought processes, which you can help them build. Increase leverage and fire yourself every day. The posts that are more relevant to you:

If I disappear, what will happen:

- https://news.ycombinator.com/item?id=25008223

Communication, alignment:

- https://news.ycombinator.com/item?id=24177646

Useful things for the team and product that add leverage:

- https://news.ycombinator.com/item?id=21808439

Communication with the team (link, and subsequent clarification):

- https://news.ycombinator.com/item?id=21598632

- https://news.ycombinator.com/item?id=21614372

Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:

- https://news.ycombinator.com/item?id=26123017

Product development:

- https://news.ycombinator.com/item?id=22827841

Management involvement as a spectrum:

- https://news.ycombinator.com/item?id=22715971

Giving a damn:

- https://news.ycombinator.com/item?id=20356222

Researching topics:

- https://news.ycombinator.com/item?id=25922120

Keeping up with a firehose of information:

- https://news.ycombinator.com/item?id=26147502

Tips to learn from videos:

- https://news.ycombinator.com/item?id=22710623

- https://news.ycombinator.com/item?id=22723586

Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:

- https://news.ycombinator.com/item?id=26179539

Less relevant to you, included nonetheless...

Understanding codebases:

- https://news.ycombinator.com/item?id=19924100

Testing pipelines, scaffolding, issue templates:

- https://news.ycombinator.com/item?id=26591067

Making the most out of meetings and leveraging your presence:

- https://news.ycombinator.com/item?id=22873103

Consulting, understanding the problem your "client", who can be your manager, has:

- https://news.ycombinator.com/item?id=24972611

Product, architecture, and impact on the team:

- https://news.ycombinator.com/item?id=24503365

Onboarding new hires to a codebase, what if it were you, improve code:

- https://news.ycombinator.com/item?id=22860716

Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team:

- https://news.ycombinator.com/item?id=21427886

On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:

- https://news.ycombinator.com/item?id=24209518

More meeting notes. Reply to a person who had trouble talking in corporate meetings:

- https://news.ycombinator.com/item?id=20323660

Congratulations and thank you,

Congratulations.

If anyone is interested, I'm happy to break down the acquisition process, what I changed, and what actually moved the needle.

Please do. Step by step.

What are you trying to accomplish? Say it's a start-up or a profitable business, you need to test your hypotheses, validate/invalidate the idea, etc. The risk is not technical, it's a business risk, so you ought to get to the truth as fast as possible, and you get there using what you're most productive in. The goal is to discover if it's "desirable, feasible, viable", not to optimize prematurely.

Say, i want to build tcp client for check connection and can deploy anywhere without install any dependency

Why? What are you trying to accomplish? Where do these constraints come from? Where does the no dependency constraint come from? Where does deploying anywhere come from? Where does checking the connection come from? What is the real problem you are trying to solve?

These questions are to avoid the XY problem, to avoid the trap of solutionism, and to get to the "Job to Be Done".

Someone once asked me how to solder a thick copper wire to a thin steel plate. When I asked him why, I listened in disbelief as he answered that the fuse blew out and that he was going to get a thicker wire and solder it so it doesn't blow out. His solution comes from an incorrect diagnosis of the problem at hand, and he asked me about the solution framed as problem, not the true, root, problem.

To answer your question: it depends.

Is it still possible for someone like me to turn things around?

Yes.

Your very first full-time job now is to get a job in the field. Take a look at MIT's "Missing Semester". It'll expose you to a panoply of tools that will get you "semi-operational". This will not make you "stand out", but it is much better when new hires are already familiar with common tools of the trade.

Be humble, courteous, curious, helpful, reliable, diligent, patient, grateful, industrious and you'll progress fast.

When you get the job, here are a few pointers that will help you ramp up fast:

Understanding codebases:

- https://news.ycombinator.com/item?id=19924100

Testing pipelines, scaffolding, issue templates:

- https://news.ycombinator.com/item?id=26591067

Making the most out of meetings and leveraging your presence:

- https://news.ycombinator.com/item?id=22873103

Product development:

- https://news.ycombinator.com/item?id=22827841

Giving a damn:

- https://news.ycombinator.com/item?id=20356222

If I disappear, what will happen:

- https://news.ycombinator.com/item?id=25008223

Consulting, understanding the problem your "client", who can be your manager, has:

- https://news.ycombinator.com/item?id=24972611

On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:

- https://news.ycombinator.com/item?id=24209518

Product, architecture, and impact on the team:

- https://news.ycombinator.com/item?id=24503365

Onboarding new hires to a codebase, what if it were you, improve code:

- https://news.ycombinator.com/item?id=22860716

Tips to learn from videos:

- https://news.ycombinator.com/item?id=22710623

- https://news.ycombinator.com/item?id=22723586

Communication with the team:

- https://news.ycombinator.com/item?id=21598632

- https://news.ycombinator.com/item?id=21614372

Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team:

- https://news.ycombinator.com/item?id=21427886

More meeting notes. Reply to a person who had trouble talking in corporate meetings:

- https://news.ycombinator.com/item?id=20323660

Communication, alignment:

- https://news.ycombinator.com/item?id=24177646

Useful things for the team and product that add leverage:

- https://news.ycombinator.com/item?id=21808439

Management involvement as a spectrum:

- https://news.ycombinator.com/item?id=22715971

Researching topics:

- https://news.ycombinator.com/item?id=25922120

Keeping up with a firehose of information:

- https://news.ycombinator.com/item?id=26147502

Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:

- https://news.ycombinator.com/item?id=26123017

Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:

-https://news.ycombinator.com/item?id=26179539

Write better. Always.

This supposes good faith from the people at hand. There are scenarios where one of the founders has decided from the start to screw over the other person, and the fallout is bound to happen when the person figures it out or tries to mediate the situation: it's not like the one who set up to screw you over will change their mind.

This is a modus operandi of some people built on finding "idealistic", "optimistic", "naïve", "gullible" people, especially technical people, of which there is no shortage in founders, to consume. These characteristics being almost a requirement for the job doesn't help.

An unbalanced equity distribution, waxing poetic about ethics, honesty, and morals... something more urgent always coming up when the equity issue is raised, etc...

Contract theory upstream.

Your work is useful when the people genuinely want to make it work but are just having trouble communicating.

I don't think the obvious choice at a terrible swimming pool would be to give up on swimming; there may be other beautiful beaches out there.

You're experienced and you seem to already have identified what you don't like. Software is practically everywhere, and it doesn't engineer itself. The aspects you talk about relate to noise that has become intolerable and there are many sectors, especially when the stakes are real, that eschew this "nonsense".

Have you considered working at places that don't "identify" as "tech companies/software companies" but where software is very present? Industry/Manufacturing, construction, automotive, aerospace, energy, logistics/supply chain, etc... In other words, places where software is a leverage to something. This may help "root" what you do in the "real world".

All these need software and they need actual, tangible, results.

What's an Htmx CEO?

Will "circle back" in a few years.

Buy my AI/LLM RAG Agentic bot to handle pull-requests and follow-ups based on HN conversations.

Hanging out on the "new" page and upvoting quality non-AI articles is an effective method of resistance.

I hang out in /ask and /asknew for my part.

PS: Hey, Paul... When are you going to close my 2021 issue[0], you already merged the pull request[1] :D

Come on, man!

[0] https://github.com/paulhoule/gastrodon/issues/10

[1] https://github.com/paulhoule/gastrodon/pull/11

If you have start again, what would be core of building saas that makes $5k per month?

1. Why $5k?

2. Find a market and customers you can reach who have a problem they are aware of, have spent money to solve, but are still unsatisfied.

Remember, most niche are already saturated. Community building and social posting does not yield to immediate revenue.

Questionable premise.

What would you do?

Same as always: find customers in a worthwhile, growing, market with a problem they're aware of and still dissatisfied with existing solutions.

The website is either not responding or giving 500 after a cached page is briefly shown, then:

  Cannot read properties of null (reading 'ce')

The ability to find and reach your ideal customer is paramount, and you're having trouble doing that. You've tried LinkedIn so far, but it's worth your while to experiment with other distribution channels.

You're trying to book meetings by reaching out ("cold") on LinkedIn in order to do what exactly? To have a conversation in which you could ask questions, and validate or invalidate hypotheses. One way to do that is to go public with your hypotheses in appropriate fora. The internet abhors someone being wrong, and your target customers will come out of the shadows and write essays proving just how little you know on the topic, and how wrong you are.

There's an old Algerian saying: "يرمي الراشي باش يجيب الصحيح", or "Throwing the brittle to pick up the solid" (meaning people who say something wrong (brittle) in order to get the correct (solid) information).

There's also "Cunningham's Law": "The best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer."

Or this: https://xkcd.com/386/

Now, you're not doing that out of deception of course. The very reason you're trying to develop a product for your target customers is that you believe some things to be broken and believe certain things to be true. You can write about those and get to validate or invalidate these beliefs. In any way, you'll get feedback and strike up conversations.

That is but one way.

I have offered Lunch and coffee as an incentive.

That would be a courtesy, not an incentive. An incentive would be to pay them consulting fees and get them as consultants to answer your questions.

There are other ways: trade shows, conventions, subreddits, Quora, etc. Where do these people gather?

You also could think of changing your messages and state the questions in your email. This might lower the activation energy: someone might not want to meet you for coffee/lunch with an open agenda, but if you state your questions clearly in your email they might think "What the heck, I can write a reply in 10 minutes and get done with it. Good action of the day: check".

The bottom line is to respect their time, and one way to show that respect is to have your thoughts and questions in order. This helps get responses.

They might not be interested, but if they know someone who might be, they might refer you to that person.

If you have a way to be useful for the person, don't hesitate. There are so many opportunities to be useful for people by connecting them to your network and solving problems for them. Someone sells something, you know someone interested? Offer to connect the two. Hook people up.

Do a Show HN here with your product, however rudimentary it may be. Also, make yourself reachable (put your contact information and your product in your profile) so people can reach out to you even after it's no longer possible to reply to this thread. Keep channels open.

I have replied to a few threads on this forum: https://news.ycombinator.com/item?id=40482961

These go from "Hired, now what?" to how to validate an idea, build product, operate a company, lead a team, etc...

I hope you find something useful in there.

Issues/tickets are split between features and bug-fixes. Positive/Negative. Issue templates that force revealing the job to be done and avoid the XY problem. Get down to root causes, not just the symptom of an issue. The analogy is not to look at the last line of a traceback. If it is a feature, why should it be implemented? Who will it serve? How many complained about it? What do analytics say? What's its impact, and what graph of possibilities does it open?

Prioritize:

- Bugs: monitor exceptions with tools such as Sentry to help prioritize bugs because you get just how many times an exception was raised. The exception traces get buried in logs; you will not notice them if you're relying on logs.

- Features: analytics tools such as PostHog to track usage and non-usage (non-consumption) and find out why customers are not using certain features.

- On-going customer support: How's your customer support? How often do you interact with users? Do you have a Slack/Discord/IRC channel people can get on right away and start ranting about some issue with some screenshots and talk with a human? This both exposes issues you were oblivious to and assigns a weight to issues you were aware of but hadn't ranked: One user who complains about an issue is one thing. Many people complaining about the same issue that prevents them from working is another thing. Use frequency and severity/impact

- On-going customer success: having to hold users' hands to accomplish something could indicate poor UX, which should nudge you to make it more intuitive. The less users need you, the less complex sales become, the more "low touch" the product becomes, the higher the odds people at an organization will adopt your product ("shadow IT", "bottom up"), the higher your chance to really sell into that organization.

- Marketing: when talking with users and when you read what they write and listen to what they say, do they use different words, names, and expressions than what you use? When you watch them use the product without helping them and scream in your head that they can't seem to click on the proper icon even though they just hovered over it and it even had a tool-tip and a label, do you adjust for that in your language?

- Resist the temptation to implement features just because other products have them or just because a few users asked for them. Wanting to please everyone only pleases shrinks. The Sirens always sing for you to jump into a sea of code and you better have wax and rope nearby.

- User feedback does unearth problems, not draw the roadmap. Listening to users' "solutions" (features) is like a physician asking you which prescription to write. I'm not saying to ignore it, but it pays to be very, very careful.

- Features that are interesting are often found looking at the whole journey of a user trying to solve a problem. What is the user trying to do? Why is he using the product to do that? Which steps come before using the product and which steps come after?

Problem solving for features:

The XY problem can be sneaky. For instance, we had built an MLOps platform a few years ago. I was doing "customer discovery" and people worried about data privacy/security and infrastructure capabilities, especially GPUs. In other words, these represented friction and increased the "sale complexity". Some users asked us to offer compute and storage, others rejected the product because it's not open-source and they don't trust it (digging deeper, they were afraid we'd die). I could've taken that and decide to "increase security/privacy", and chase the infra route to reduce that friction, which was what most companies were doing. Instead, I decided to completely bypass it and use the user's infrastructure by integrating with it: the compute jobs would now happen on the user's own clusters and on the user's own data sources without transiting by our platform. Also, we were able to die without losing users' work. That's an example of circumventing a sales obstacle/objection with technical means. Even more so, the rationale was that by going that route (using their own compute and storage), we wouldn't need to find a budget with their CFO, because their compute and storage was already budgeted for. In other words: staying true to orchestration and integrating with the user's infra.

It could be a variety of things and we lack information, so I'll give a, hopefully useful, generic answer.

We did get some validation and we are generating low 3 digit revenue. But, that’s not enough.

- Does your product save money, make money, or make life "easier"?

- Did your users find you or did you find them?

- How many people have you talked with and what have you learned?

- How did your users find you?

- How did you find your users?

- What do they have in common?

- Are they in the same industry?

- Are they in the same function?

- Have you talked with them?

- What is it that they're trying to accomplish with your product? (I'm not asking you what your product does, I'm asking what they are trying to do)

- How do they describe your product? Are there words that come up again. Do they describe it differently than you do?

- What is your conversion graph (or "funnel" with the different drop-offs) like?

- What's your product's sale complexity? (high touch? low touch? do they self-serve? Do they need a demo? Do they struggle?)

- Is the user the person who pays for the product or is it someone else?

- What's your features usage like? (are they using all the features and if not, why not and what are they using to solve the problem you built the features to solve?)

- What did the people who said "NO" tell you? What are the reasons they will not use your product?

When I was in EE at university, I worked on heart anomaly detection and multi-phase flow classification for oil & gas. The papers I was reading used synthetic data with a nice noise dust sprinkled on it. Meanwhile, I worked on data from hospitals acquired on restless, sweaty, hairy, dudes with rusty, banged up electrodes and abused probes.

Needless to say, the data I saw on these papers looked nothing like the data I worked with, whether from hospitals or what I saw at Schlumberger in the Sahara.

The real world tends to be ... interesting.

Your question is "Is there any demand for Personal CV/Resume website?". The short answer is: There is demand for employment.

What problem are you actually trying to solve? If you were looking for a job, would writing a résumé be the biggest hurdle for you?

People write CVs to apply for jobs, and they apply for jobs to work, and they work to have an income which they use to go on about life.

Now, what we have here is selling soap to hungry people who are broke. A CV builder is like soap in a restaurant; it is important to wash your hands at a restaurant, but you don't go to a restaurant to wash your hands.

It can be a hook to do other things, like discover your customers, etc. but your would be users eventually come to you to get a job. How do you get them there? What are the sides of this market?

You have a distribution problem. Ideally, anyone who uses your CV builder gets employed. Which means they get hired. Which means there's an employer on the other side who received that CV. How do you plug in that process?

Maybe go upstream and do some fine targeting, maybe a choice of the point of market entry: start with people who are looking for their first job and who've never had a CV. You shouldn't wait for them to find you; they may not even be aware they need a CV. Maybe you can start with employment agencies where you live. Many countries have agencies where unemployed people register to get notified when a job matching their skills is available. Maybe going to high-schools or colleges and getting your users there, on the spot, helping them making a CV.

Maybe fine-tune where you plug in that value chain: the builder is just to get the data in order to make recommendations to jobs that match their skills that they weren't even aware existed.

Get to know who you're serving and what serving them is about.

This response is about the feasibility of this, not about its viability as a business or if it is worth your while.

I usually write the README and documentation before writing the code. I then shop it around and ask people if it makes sense.

The initial version of the code is stubs that, if you follow the code examples given in the documentation, return hard-coded values.

I went to the extreme of giving the docs to non-developers who've never written a single line of code in their entire life, giving them an interpreter, and asking them to follow the docs without providing any help. If they could do it, developers wouldn't have a problem.

One must resist the temptation to help and should only observe how the users "misuse" the code. When they make a mistake, it's usually a good indicator of bad design, which is promptly corrected.

There's also a good tool called asciinema[1] that helps you record terminal sessions.

- [1]: https://asciinema.org

What was the success of other means, such as sugars and proteins? Something like glycocalyx or polysaccharide capsules? Or HIV like deployment gp41/gp120?

May your parents forever live in your heart.

I'm grateful, but I also feel very alone and a little lost. I’m not sure what to do next — with my time, my energy, or even with my life.

You may be tempted to fill your time and spend your energy and money on things that take your mind off of "life". Drugs, alcohol, gambling, carnal pleasures, clubbing, etc. It will spiral and you'll lose your life, health, and wealth. You are a prime target for leeches and parasites who smell a lonely soul with a full wallet a mile away.

Were you to need an addiction to "cope" and "avoid reality", make it an addiction that could:

1 - fade a way

2 - not ruin your health, wealth, and time.

3 - become a net positive

For instance: picking up a sport (judo, jiu-jitsu, wrestling), hiking, pursuing a degree, going to workshops that make you work with your hands (masonry, ceramics, carpentry, agriculture, stonewalls, manufacturing/fabrication). These may be coping mechanisms and just a "transition", but they are virtuous coping mechanisms and I don't see you regretting your masonry classes; on the contrary, you will have acquired a skill for life even if/after your interest "fades away", and may even become your business.

In other words, please be very careful and deliberate about how you spend your health, time, and money.

You'll also be tempted to brood and stay home or on the contrary, be out all night and chasing pleasures, hence my recommendations on physical activities (judo and masonry) for you really ought to stay connected with your body and physical being especially now. If you work out, don't stop. If you don't, start.

We earned non-zero revenue but very small and not enough to say they were living expenses. We did some amount of marketing but not enough. My introspection tells me that this happened because we built without good ICP or any feedback from users.

You say that you developed without "good ICP" or feedback from users, but you still managed to have "some" revenue. You may be onto something provided more people become customers. In other words: enough people hear about your product and of those, enough people make a purchase, and of those enough people keep paying you.

The problem may or may not be ICP related, and may or may not be feature-set related, but I'm willing to wager that it somehow is not enough customers purchasing.

It is unclear from the "not enough marketing".

Tinkering with these variables is not mutually exclusive: you can have "more marketing", and have more feedback starting with your existing customers, and get more marketing from your existing customers in the form of recommendations or getting other people to use the product, or introduction into their organizations, etc.

How and where do I find users to talk to? Where do I find these cohort of people that can at least respond to user interviews or MVP feedback. I don't have good network and that hurting most.

You solve a problem for users who are aware of the problem, are aware it is a problem, have spent coins to fix it or have a say in some coins being spent on fixing it, are unsatisfied.

One of the ways to speed this up is to go higher up the abstraction scale and target a vertical/sector, but not too high or you'll spend so much time you'll never ship, and not too low without being careful not to get locked-in. This way, you get the distribution of someone stronger. Call it piggy-backing, gravity assist, leverage, whatever you want.

What a mouthful of abstract new-age mumbo-jumbo... Let's do an example:

Imagine you're solving a problem for an airline. Going up the abstraction layer is to work directly with their ticketing system provider, say Amadeus. Now, instead of just one airline, how many airlines use Amadeus? The next step is to talk with Amadeus. The benefits is that its distribution is much, much, stronger than you trying to get with multiple airlines, and your solution will stay mostly as is because you're using the same data model.

If you're solving a problem for hotels, go one notch up the abstraction layer and look-up software vendors for that industry/vertical. Get compatible with their software/data model. Distribute. Does it have a marketplace? An ISV page (Independent Software Vendor)?

What's also beneficial is if there's a conference for that industry: do they all get together at some point somewhere? Is there a standardizing or regulating body, an authority of some sort, mandatory registration with an organization? Is there a ledger somewhere? A trade association they belong to? A union? Where do they congregate?

As a sidenote, it has become miraculously difficult to get a job as a developer in late 30s.

For every "software" position at a "software company" that knows it is, there are thousands at companies that don't know they are. Oracle and Microsoft didn't get to that size selling to "tech companies". There are huge organizations running on VB macros or FileMaker or WinDev, factories with so many PLCs and no love for humans, etc. "You may find in the sea what you don't find in the river."

* I have a trained ML model that solves a niche task really well — but turning it into a full-blown app seems like overkill.*

A RESTful API, either metered billing or otherwise with something like Lago[0]

* I’ve written a CLI tool that processes log files better than anything else I’ve found, but it’s too specialized to justify making a company out of it.*

Enterprise. Find organizations that have this problem, know they have this problem, spent money to solve it, but aren't too satisfied with the solution.

* I built a few small functions in different languages (Python, Go, Rust) that do neat things — data cleanup, API scraping, PDF generation — but none of them are “products” by themselves.*

A suite for organizations that need that.

All these can be your way into these organizations to get to know them, identify their problems, uncover patterns or segments, etc.

- [0]: https://www.getlago.com/

One method that works really well is the following:

- Unplug your laptop's charger

- Disconnect from the internet

- Work using only using your battery charge and the documentation on your laptop

If you find that you need an information about something that's in a doc you don't have, only connect to the internet to download it, then disconnect. Nothing more.

Batteries will only last for about two hours when they're not new, and you have the docs on your machine without distractions online. This forces you to work only on what you're working on, and do it fast as the battery is discharging so you catch yourself more often "drifting" in your thoughts, and you'll get better at catching yourself and focusing again, because "Quick! It's discharging!"

I know it sounds silly as you can just connect to the internet or plug your charger, but it really works. Its real job is to remind you to focus and get things done.

Try it, and you'll find soon enough just how much of your attention was scattered, but you'll be weaning as soon.

It depends on the size of the team, and how well you run meetings (agenda, specific issues to be discussed, how well these issues are written, precise topics), how large the project is, etc.

You can have a very tight feedback loop (sometimes writing experimental code and coming up with a proof-of-concept during the meeting) if you run a tight ship.

On the other hand, plugins imply a plugin architecture which means we can make our plugins that others could hate on. It is how life goes :-D

David Mamet's "Masterclass" on dramatic writing helped me with programming believe it or not.

Bob Woodward has such a course. It is good and could be of use to you.

May he forever live in your heart.

Generosity, empathy, pedagogy, and match-making go a long way.

I don't use any of these out of ignorance first, laziness second, and incompetence third.

I didn't know about them, and I had spent a lot of time with the documentation and code of everything I touched (language, dependencies, etc). Looking things up reinforces this. The value of a feature such as autocomplete is marginal to me as a function of the effort I have to make to learn how to use it properly, the frustration of using it improperly, and the added steps to fix a blunder, so I just don't bother with it.

I also have a habit of having the documentation/book/code of a dependency open nearby and doing my look-ups there.

A lot of time is spent refining existing code, debugging, optimizing, refactoring, etc...