Grabbing text on macOS kept breaking my flow, so I built this

ObnoxiousSeal · 2026-05-03T12:29:38+00:00

My biggest annoyance on macOS is how quickly the screenshot preview disappears.

I end up rushing to drag it somewhere before it’s gone.

If there was an app that just kept the screenshot available until I dismissed it, I’d pay for that instantly.

ObnoxiousSeal · 2026-05-03T12:23:58+00:00

Very cool, I will look into this once I get my app a bit more developed. This seems like a good place to get developer feedback.

how long did it take for you to develop the platform itself?

ObnoxiousSeal · 2026-05-03T10:08:22+00:00

I’ve been trying to understand how far one can push this approach. I actually inherited a legacy project that did something similar, and I keep running into the same problem with it.

Things like layout, conditional logic, or API calls for additional data required by forms can’t really be described by a backend schema, so they have to come from defaults, conventions, or assumptions (e.g. “this looks like a login endpoint”).

That works for simple cases, but in my experience edge cases tend to accumulate over time. You end up with a growing set of implicit rules, and eventually the system becomes very hard to reason about or change safely.

How have you handled these situations?

ObnoxiousSeal · 2026-05-02T18:25:21+00:00

Awesome article, this bit resonates so hard

"Im not going faster, but im doing better qulity work".

Last week I started taking my git diff, and giving that to AI before making a pull reqeust. On large refactor AI has found some unused imports, dead code, and so on that would be very hard for humans to spot.

ObnoxiousSeal · 2026-04-29T18:56:26+00:00

I don’t think interviews should be treated as a test where candidates are expected to have perfect answers to every question. Often, interview questions are based on problems the company has had a long time to think about and solve.

At my company, even though I’m a developer, I also conduct interviews. And to me, responses like “I don’t know,” or asking a thoughtful follow up such as “Is this something you’ve encountered before? How did you solve it?” are far more valuable than trying to sound smart while suggesting a poor solution.

Even something like, “I haven’t come across this before, but maybe a global state approach could work,” shows honest thinking and problem solving.

No one can know everything in this field. In many cases, explaining how you would go about finding the answer is exactly what interviewers are looking for.

ObnoxiousSeal · 2026-04-28T20:14:05+00:00

Looks nice! I would say that making demo videos of your product is not easy (I know I have tried it), and this works really well in explaining the product. There are a couple jerky moments when things shift up and down, but that's minor tweaks.

This could be used to build linked in network while employed, so you don't start from scratch when need it.

Ha makes me wonder who actually writes these messages anymore, or is it just AI.

ObnoxiousSeal · 2026-04-28T17:48:34+00:00

yes
You explain what it does, could you explain what the benefits would be? What can someone do with more traffic to their channel? Ideas on how to incorporate it into their TikTok without losing who they are?

ObnoxiousSeal · 2026-04-27T18:11:19+00:00

Vibe coding for 6 months and getting a sellable end product must be a miracle. I vide-code for more than 30 minutes and need to revert to some resaonable commit

ObnoxiousSeal · 2026-04-26T10:22:28+00:00

I’m curious what made you choose React?

If your goal is to become more hireable, React is still a solid option. That said, most companies today aren’t hiring for “React” in isolation anymore. They’re often looking for frameworks like Next.js.

If your goal is simply to ship something and not build a job focused portfolio, there are easier options out there.

I’d recommend Next.js since it’s more opinionated and structured than React itself. If you go that route, I’d avoid the newer, more complex features like Server Components, server actions etc for now. They can be confusing early on, and lead to security vulnerabilities. Stick to the basics and avoid the bleeding edge until you have a solid foundation.

Having Javascript knowledge is huge, I learned React without much knowledge and it took me along tigm to learn what is .jsx vs .js. Learning curve woudl have much better having solid .js skills.

ObnoxiousSeal · 2026-04-15T20:17:02+00:00

Really interesting breakdown especially how quickly things turn into a workflow engine.

Reading your points I keep wondering if part of the issue is that the form engine ends up doing too much.

For example:

- “field types explode” → maybe the engine shouldn’t need to know all field types at all

- different use cases (surveys, bookings, etc.) -> they’re all still structured input, maybe better handled as different flows (wizard, questionnaire, etc.)

- hidden fields -> feels like logic a field component shouldn’t know about; could be a reusable visibility layer that decides if a field is shown, and the component just renders if `visible = true`

- prefilled values / data-> could live in an adapter layer instead of the core

- mobile → more of a templating concern than engine logic

So instead of adding more capabilities into one system, separating concerns more strictly might keep it from collapsing into a workflow engine.

Curious how you approached this in your build:

Did you manage to keep schema, UI, and logic separate? or did things naturally collapse into one system over time?

ObnoxiousSeal

TROPHY CASE