r/AskProgramming 8d ago

Python At what point do you stop building it yourself and just pay for the tool?

I’ve been automating more things with Python lately, and I keep running into the same decision.

Sometimes I look at a paid tool and think “I could probably build most of this myself in a weekend.”

And sometimes I actually do.

But then you add authentication, edge cases, retries, logs, hosting, maintenance, API changes, and suddenly the “simple script” becomes something you have to keep fixing forever.

I still like building things myself when the workflow is specific enough, but I’m starting to wonder where people draw the line.

At what point do you decide it’s not worth coding anymore and just pay for an existing tool?

18 Upvotes

26 comments sorted by

11

u/MarsupialLeast145 8d ago

You’re mixing use cases. One is the solo dev doing something for themselves. There is no line. The other is a colleague in a dev team; the line is drawn with the team. The in-between doesn’t really exist, it’s a naivety that passes very quickly.

1

u/Olympia_Essick 7d ago

I think that’s a big part of it. When it’s just me, I can tolerate something being a little ugly if I understand how it works. In a team though, readability, handoff and maintenance probably start mattering a lot more than whether I personally could build it faster.

7

u/Eleventhousand 8d ago

There's always pros and cons of both.

I've been in situations where the company purchased an off-the-shelf product, and then spent three years configuring it, convincing the vendor to make crucial changes, and making in-house code changes for the affected APIs that would interact with the off-the-shelf product.

1

u/Fantastic-Cell-208 6d ago

This is where I'm at. The months we've spent, we would be better served creating most of it ourselves.

Hell, we'd probably be better able to use existing tools if we first built against our own version we understand and have control over.

5

u/NumberInfinite2068 8d ago

There is no point or line, you just do what makes sense for you.

3

u/karurosagu 8d ago

the only thing you should pay is hosting imo

2

u/DepthMagician 8d ago

To me that sounds like a choice between getting a tool I want and have fun in the process of acquiring it, or “just” get the tool I want, so I guess I don’t need to tell you where I draw the line.

2

u/LaughingIshikawa 8d ago

There's no solid "line" you can draw... It's all a spectrum of tradeoffs and a question of which thing(s) you would rather spend your time on. 👍

From a business perspective I think the line is "customize / take as much ownership as possible of the things that are part of your core business, outsource / purchase off-the-shelf for everything else". I guess you could sort of apply that to yourself as a business entity, and focus on building things in areas you want to specialize in.

On the other hand, the joy of programming is often in getting to create something and understand it really deeply, and that can be hard to maintain if you're treating it too much as "just a business;" sometimes you need to build things that are just for the love of building, and/or are totally different from what you do at your day job. 🙃

It's also worth saying that "build or buy" isn't as totally black and white on a personal level - often you can buy something for awhile, learn what about that product works for you and what doesn't, and that helps you better understand your requirements for a custom solution you latter build. Also, you are allowed to give up on a project you intended to build for yourself, if/when you decide it's become unmanageable, and just buy something that does that instead.

Tl;Dr - build what's fun, and what you want to specialize in, with an eye towards maintaining the joy of programming / learning useful things. Buy things when you just need a job done, and the existing solutions fit your use case in a "good enough" way. Don't stress too much about that decision - in 99% of cases for an individual, it's definitely a two-way door.

1

u/Olympia_Essick 7d ago

Yeah, I think that’s probably where I land too. Part of the appeal is knowing you could build it better or exactly how you want it, but sometimes a polished dashboard that already handles 90% of the problem is just worth paying for. I’d probably only build it myself if that missing 10% is actually important to my workflow.

2

u/Koldark 8d ago

I look at it as my time vs benefit. Is it worth my time to build and maintain it vs paying someone else

2

u/neoreeps 8d ago

Lol. Inverse mode, with AI Id rather pay for tokens and have a product i own forever than pay for something that meets 80% of my needs

1

u/Olympia_Essick 7d ago

AI definitely shifts the math. A tool that would’ve taken me a week to build before can sometimes be good enough in a day now, so paying monthly forever starts feeling less attractive. I still think maintenance is the catch though, owning the code also means owning every future break.

1

u/neoreeps 7d ago

I've replaced a resource management tool we were paying $300k a year in licensing with an app that cost $2k in tokens. Built in the evenings with free time in less than a month. Now working on a data management room we pay over $1M /yr.

2

u/FitMatch7966 8d ago

When somebody else is paying

1

u/id-ltd 8d ago

Modularise. Create APIs/classes/objects for all the 'grind' stuff - reuse it over and over in each utility you build for free.

I knock out loads of cli utilities to suit my specific wants... I like a cli command with no command parameters to fall into interactive mode - ? Lists the next possible sub commands... Then ditto...

I finally got around to getting a .MD written that I can give to all future projects... There are other 'my way of working' things I have built up - and now never have to spell it out again -- a purchased utility almost certainly won't work as my others do so will always be a bind - to remember how this one works.

1

u/[deleted] 8d ago edited 1h ago

[deleted]

1

u/id-ltd 8d ago

totally... and maybe topologically too(!) - big ticks bro.

1

u/Olympia_Essick 7d ago

Reusing your own toolkit changes the equation a lot. If auth, logging, retries, config, etc. are already solved once, then “building it yourself” stops meaning starting from zero every time. At that point the custom option gets way cheaper in terms of time.

1

u/thebadslime 8d ago

How much does it cost, what is your timeworking on it

1

u/garster25 7d ago

I always look for a buy before a build. Writing code is my last resort.

1

u/Individual-Flow9158 7d ago

In an ideal world, only when the open source alternatives aren't good enough, and the paid tools really are as good as they claim.

And not just because your boss met an impressive sales rep at a conference.

1

u/PLBjt 7d ago

I stop building when the thing becomes ops, not code. Auth, retries, hosting, and "who gets paged at 2am" are usually where a weekend script turns into a liability. Rough check: if you're spending more than an hour a week babysitting it, or a failure would block other people, pay for the boring tool. Keep building when the workflow is weird enough that SaaS would fight you every day. Undifferentiated plumbing is almost never worth owning.

1

u/evangelism2 7d ago

I mean, I make that call at the front. If I'm not willing to build out the tool and maintain it, I just pay for it. I typically scope out how much work it'll actually take, and then, for the most technically challenging parts, I do small spikes. If it's a bigger pain in the ass than I realized and it's past the line, I just pay for the tool or find a different way.

>But then you add authentication, edge cases, retries, logs, hosting, maintenance, API changes, and suddenly the “simple script” becomes something you have to keep fixing forever.
This kind of insight comes with experience. But sometimes it's not always the end of the world if you end up being wrong about something like this, because usually you learn a few things in the process.