DEV Community: altuntas gokcer

The Most Dangerous Feature Request Is the One That Sounds Reasonable

altuntas gokcer — Sat, 26 Sep 2026 14:22:38 +0000

The Most Dangerous Feature Request Is the One That Sounds Reasonable

Some feature requests are easy to reject.

“Can you rebuild the entire product for my very specific workflow?”

Probably not.

But the dangerous ones are usually much more reasonable.

“Could you add one more filter?”

“Can we have another user role?”

“It would be useful if this sent a notification.”

Nothing sounds wrong with any of those.

And that’s exactly the problem.

A feature request is not the same thing as a product decision

When a user asks for something, they’re usually describing a solution.

But the useful part is often hidden underneath it.

Someone asks for:

“Export to Excel.”

Maybe what they actually need is:

“I have to send this report to my manager every Friday.”

Someone asks for:

“More notification settings.”

Maybe the real problem is:

“I keep missing the one event that actually matters.”

Someone asks for:

“Another dashboard.”

Maybe they’re really saying:

“I can’t quickly understand whether things are going well.”

If you immediately build the requested feature, you might solve the suggestion without solving the problem.

One request can feel much bigger than it is

Early-stage products make this especially difficult.

You might only have a handful of users.

One person asks for something very confidently.

They explain exactly how it should work.

Suddenly it feels important.

But confidence isn’t frequency.

And frequency isn’t always importance either.

Three users asking for a feature can still be less meaningful than ten users silently struggling with the same workflow.

That’s why I’m starting to care more about patterns than individual requests.

I like asking one extra question

Before turning feedback into a roadmap item, I think there’s a useful question:

“What were you trying to do when you realized you needed this?”

That changes the conversation.

Instead of:

“I need bulk editing.”

you might hear:

“Every Monday I update the same field for 80 customers.”

Now you understand the job.

And maybe bulk editing is the right solution.

Or maybe automation is.

Or maybe the field shouldn’t need to be updated manually at all.

The feature request gives you a direction.

The context tells you whether it’s the right direction.

AI makes this problem more interesting

This is something I’ve been thinking about while working around built.new.

AI has made adding features dramatically cheaper.

That’s useful.

But it also removes some of the natural friction that used to force prioritization.

If a request takes three weeks to build, you ask a lot of questions first.

If AI can generate it in twenty minutes, the temptation becomes:

“Why not just add it?”

But implementation cost isn’t the only cost.

Every new feature creates:

another state
another decision
another thing to test
another thing users need to understand
another thing that can break later

The feature might be cheap to generate.

The product complexity isn’t.

Maybe AI should help interpret feedback too

Most AI product tools focus heavily on execution.

Generate this.

Change that.

Add this screen.

Connect this API.

But there’s another interesting problem:

Should this request become a feature at all?

Imagine an AI system seeing ten pieces of feedback and helping identify:

which requests describe the same underlying problem
which ones are one-off preferences
which workflow is creating repeated friction
which request conflicts with the product’s core use case
which problem could be solved without adding another feature

That feels much more valuable than blindly converting every request into code.

Feedback should create questions before it creates features

I’m trying to think about feedback more like this:

request → context → pattern → decision → build

instead of:

request → build

It’s slower by one step.

But that one step might save a lot of unnecessary product later.

Because users are often very good at telling you where something hurts.

They’re not always responsible for designing the solution.

That part is still the product decision.

So I’m curious:

What’s a feature your users asked for that you eventually realized they didn’t actually need?

Building Got Easier. Distribution Got Harder.

altuntas gokcer — Thu, 24 Sep 2026 12:46:06 +0000

Building Got Easier. Distribution Got Harder.

It has never been easier to build software.

A small team can now do things that used to require designers, developers, infrastructure work and weeks of coordination.

Sometimes one person can get surprisingly far.

That’s exciting.

But it creates another problem:

If everyone can build faster, being able to build is no longer enough to get attention.

The bottleneck moves.

From production to distribution.

Shipping used to be the impressive part

A few years ago, saying:

“I built and launched this product myself.”

was already interesting.

Now timelines are full of:

built this in a weekend
shipped an MVP in a day
generated this with AI
launched another SaaS

The tools genuinely are getting better.

But the easier building becomes, the more products people have to choose from.

So the question changes from:

Can you build it?

to:

Why should anyone care?

Distribution isn’t just posting links

I think this is where a lot of founders get frustrated.

They spend weeks building.

Then launch day arrives.

They post the link in a few places.

Nothing happens.

And distribution starts feeling like some mysterious skill separate from product building.

But I’m starting to think good distribution often looks much less like promotion.

It looks like participation.

Answering questions.

Sharing things you learned.

Explaining mistakes.

Publishing useful research.

Helping someone solve a problem even when they never click your product.

That is slower than dropping a link.

But it also creates something a link alone can’t create:

trust.

Community changes the relationship

I’ve been spending more time in founder and builder communities recently.

One thing becomes obvious very quickly.

People can tell when someone only arrived to promote something.

And they can also tell when someone is genuinely part of the conversation.

The second approach takes longer.

You post.

Someone disagrees.

You respond.

Someone asks a question.

That question turns into another discussion.

Eventually people recognize the topics you keep talking about.

That feels much more valuable than one post getting a temporary spike in clicks.

Because distribution starts becoming a relationship instead of an event.

Useful content compounds better than announcements

This is something we’re also experimenting with around built.new.

I’m involved with the project.

Instead of only talking about the product, we’ve been trying to publish useful material around the problems people already have.

Comparisons.

Tests.

Lessons from other builders.

Practical guides.

Research.

We’ve been collecting that work on built.new Learn.

The idea is simple:

If someone learns something useful before they ever use the product, that relationship starts differently.

You’re not asking for attention first.

You’re earning some of it.

AI probably makes this more important

AI can help generate:

landing pages,
emails,
posts,
videos,
code,
designs.

So content itself is getting cheaper too.

That means simply producing more probably won’t be enough.

The valuable part becomes:

having something worth saying.

A real observation.

A useful experiment.

A mistake.

A result.

A strong opinion backed by experience.

A conversation that continues after the post.

AI can accelerate the output.

It can’t manufacture genuine relevance.

Maybe distribution is part of the product now

I used to think about the process like this:

build → launch → market

Now I think it’s closer to:

talk → learn → build → share → listen → improve

The conversations before the build affect the product.

The conversations after launch affect the roadmap.

The content brings new people into those conversations.

Everything starts feeding everything else.

So while building software is becoming dramatically easier, I’m not convinced building a company is.

The difficult part is simply moving somewhere else.

And right now, I think a lot of that difficulty sits in earning attention and building trust.

For people building something today:

What’s harder for you right now — building the product or getting the right people to care about it?

What Real Users Made Me Simplify

altuntas gokcer — Thu, 24 Sep 2026 12:42:24 +0000

What Real Users Made Me Simplify

There’s a strange thing that happens when real people start using something you built.

Before launch, complexity can feel like progress.

More settings.
More options.
More screens.
More flexibility.

Then someone actually tries to use the product.

And suddenly the most useful feedback isn’t:

“Can you add another feature?”

It’s:

“Why do I need to do this?”

That question can be brutal.

But it’s usually useful.

Users expose complexity you stopped noticing

When you build a product every day, you become familiar with it.

You know where everything is.

You understand why a button exists.

You know what happens after each step.

The user knows none of that.

They arrive with one goal.

And every unnecessary decision you make them take becomes friction.

A flow that feels obvious to you might feel confusing to someone seeing it for the first time.

That’s why I’m starting to think one of the most useful things early users give you isn’t feature ideas.

It’s permission to remove things.

Repetition matters more than one comment

One person getting confused doesn’t always mean the product is wrong.

But when the same thing happens repeatedly, it becomes difficult to ignore.

People skip the same step.

They fail at the same action.

They ignore the same option.

They ask the same question.

That repetition is a signal.

And often the answer isn’t adding another explanation.

It’s making the product simpler.

Simple doesn’t mean less capable

I used to think simplification meant removing value.

Now I think it often means making the value easier to reach.

There’s a difference between:

having more features

and

making the core job easier

Imagine a booking product.

Maybe it has:

advanced analytics
multiple staff roles
loyalty points
notifications
custom settings
several payment options

All useful things.

But if the actual booking flow takes eight confusing steps, none of that matters very much.

The user came to book something.

The core flow has to win first.

Real usage changes the roadmap

This is something I’ve been thinking about a lot while working around built.new.

I’m involved with the project, so obviously I’m close to the problem.

One thing I find interesting about AI-assisted product building is that adding things has become incredibly cheap.

Removing things is still a product decision.

AI can generate another screen in seconds.

But it can’t make an unnecessary screen valuable just because it was easy to build.

That’s why the loop after launch matters so much:

build → ship → observe → simplify → improve

The first version gives you a hypothesis.

Real users tell you where that hypothesis was wrong.

Maybe product progress should sometimes look smaller

We usually show progress by adding things.

New feature.

New integration.

New dashboard.

New workflow.

But some of the best product changes might look like:

one less step
one less decision
one less setting
one less screen
one less explanation

The product becomes smaller.

But the experience becomes clearer.

And that can be a much bigger improvement than another feature release.

If you’ve shipped something before:

What did real users make you simplify?

Was it onboarding, navigation, pricing, a feature, or something you originally thought was essential?

The Most Useful AI Feature Might Be a Better Question

altuntas gokcer — Tue, 22 Sep 2026 09:23:53 +0000

The Most Useful AI Feature Might Be a Better Question

A lot of AI builders are getting better at answering prompts.

But I’m starting to think the more interesting capability is asking better questions before the build starts.

Imagine typing:

Build me a booking app.

The obvious response is to start generating screens.

But there are a few questions that probably matter more first:

Who is booking?

Who is accepting the booking?

Does someone need to pay?

Is availability fixed or dynamic?

Does the business have one staff member or ten?

What actually needs to exist in version one?

Those answers can completely change what should be built.

And that’s the part I find more interesting.

The question isn’t only:

“How fast can AI build this?”

It’s also:

“Can AI help me avoid building the wrong version?”

Faster building can create a different problem

When implementation gets cheaper, adding more starts to feel harmless.

Need notifications?

Add them.

Team accounts?

Sure.

Analytics?

Why not.

A mobile version?

Maybe that too.

The problem is that a bigger first version doesn’t always give you better answers.

Sometimes it gives you more noise.

If ten things are happening at once, it becomes much harder to understand what users actually care about.

That’s why I think AI builders may need to become better at reducing scope, not just expanding it.

Sometimes a good AI should interrupt you

This is something we’ve been thinking about at built.new.

I’m involved with the project, so I’m obviously close to the problem.

But the part I’m more interested in isn’t how much the AI can generate.

It’s whether it can help narrow the idea before building the wrong version.

Who is this actually for?

What problem are we solving first?

What belongs in version one?

What can wait?

What are we trying to learn from the first real users?

Those questions aren’t as flashy as generating five screens in 30 seconds.

But they can completely change the quality of what gets built.

I’d rather have an AI ask me one annoying question now than help me build five unnecessary screens faster.

A booking app is a good example

Let’s say someone wants to build a booking product.

The first instinct might be to generate:

user accounts
staff accounts
payments
notifications
loyalty points
analytics
reviews
referrals
subscriptions
admin dashboards

All of those might eventually make sense.

But maybe version one only needs:

availability
booking
confirmation

That smaller version gives you a cleaner question:

Will people actually use this flow?

If the answer is yes, great.

Now you have a reason to add the next thing.

If the answer is no, you learned before spending time polishing features nobody needed.

AI should probably help with judgment, not just execution

For a while, the benchmark for AI builders has mostly been output.

How fast can it generate?

How many screens?

How many integrations?

How much code?

Those things matter.

But I think there’s another benchmark that might become more important:

How much unnecessary product did the tool help you avoid building?

That’s harder to show in a demo.

But for someone actually trying to build a useful product, it might matter more.

The future of AI app building probably shouldn’t only be:

“Tell me what you want and I’ll build it.”

It could also be:

“Before we build that, do you actually need it yet?”

And I think that’s a much more interesting direction.

When you use an AI coding or app-building tool, would you rather have it simply follow instructions, or occasionally push back and ask better questions?

What Did You Deliberately Leave Out of Your MVP?

altuntas gokcer — Tue, 22 Sep 2026 09:21:02 +0000

What Did You Deliberately Leave Out of Your MVP?

Most MVP posts show what made it into version one.

I’m starting to think the more interesting list is everything that didn’t.

Because deciding what not to build is probably one of the hardest parts of making an MVP.

Especially now.

AI has made implementation so fast that adding another feature barely feels like a decision anymore.

Authentication?

Add it.

Notifications?

Sure.

Team accounts?

Why not.

Analytics?

Might as well.

And suddenly the “MVP” is carrying ten different assumptions at the same time.

More features don’t always mean a better MVP

The point of an MVP isn’t to look complete.

It’s to learn something useful.

If your first version includes too many workflows, features and user types, it becomes harder to understand what actually worked.

Let’s say you’re building a booking app.

You could easily start with:

staff accounts
loyalty points
advanced analytics
referrals
reviews
subscriptions
multiple payment methods
custom dashboards

All of those could be useful later.

But maybe version one only needs:

availability
booking
confirmation

That smaller product gives you a much cleaner question:

Will people actually use this booking flow?

If they do, great.

Now you know what to build around.

If they don’t, you’ve learned something before spending time polishing features nobody asked for.

The hard part is often saying “not yet”

I think this is becoming more important as AI development gets faster.

Before, if a feature was going to take a week, you naturally stopped and asked:

Do we really need this?

Now that same feature might take an hour.

And “we might as well add it” becomes very easy.

But cheap to build doesn’t necessarily mean useful to build.

Sometimes the best product decision is:

not now.

Not because the feature is bad.

Just because it doesn’t help answer the first important question.

Smaller products create clearer signals

If you launch a focused MVP and 100 people try it, the behavior is easier to read.

You can see where they stop.

What they understand.

What they keep using.

What they ask for next.

But if version one already has 20 features, the signal gets messy very quickly.

More software can actually make learning harder.

That’s why I’m starting to think MVP quality should be judged partly by what was intentionally left out.

Not just by what got shipped.

So I’m curious

What’s one feature you were sure you needed in version one, but ended up leaving out?

And did you ever come back and build it?

The Best AI App Builder Might Be the One That Tells You “Don’t Build That Yet”

altuntas gokcer — Mon, 21 Sep 2026 12:10:22 +0000

There’s something strange happening with AI development.

For years, software teams had to fight for every feature.

Features were expensive.

They took engineering time.

They needed design.

Testing.

Deployment.

Maintenance.

So people were forced to prioritize.

Now AI can generate features incredibly quickly.

And that sounds like an obvious improvement.

But it creates a new problem:

When building becomes cheap, saying no becomes harder.

“Can we build it?” isn't the useful question anymore

Imagine you're building a booking app.

You start with something simple:

customer chooses a time
business confirms the booking

Then you realize AI can add things pretty easily.

So version one becomes:

user accounts
staff accounts
loyalty points
analytics
notifications
subscriptions
referrals
reviews
AI recommendations
custom dashboards

Technically, maybe you can build all of it.

But you're now answering a completely different question.

You aren't testing:

“Will people use this booking flow?”

You're testing ten assumptions at the same time.

If the product fails, you won't even know which assumption was wrong.

Faster building makes product judgment more important

AI is reducing implementation cost.

It isn't reducing the cost of building the wrong thing.

That cost just appears somewhere else.

You spend time fixing features nobody needed.

Users get a more complicated product.

Your analytics become harder to understand.

The product becomes harder to change.

And suddenly the speed advantage starts disappearing.

This is why I think one of the most valuable features of future AI builders may be something surprisingly simple:

restraint.

An AI builder should probably ask questions before it starts building

Instead of immediately generating 15 screens, I'd rather have the system ask:

Who is this product actually for?

What is the one thing that user needs to accomplish?

What absolutely has to exist on day one?

What can wait?

Who pays?

What assumption are we trying to test?

Those questions aren't as visually impressive as generating a dashboard in 30 seconds.

But they can save days of unnecessary work.

Maybe weeks.

Sometimes the best generated feature is no feature

This is something we're thinking about with built.new.

Full disclosure: I'm involved with the project.

The interesting part to me isn't simply giving someone a prompt box and generating as much software as possible.

It's helping someone move from:

“I have an idea.”

to:

“This is the smallest useful product I should actually build.”

That can mean defining the product before generating it.

Thinking through who it's for.

Planning the important screens.

Separating the things needed now from the things that can wait.

And sometimes pushing back on unnecessary scope.

Because if AI can build ten features quickly, that doesn't mean ten features belong in the MVP.

Small products create cleaner signals

Imagine you launch an MVP with one important workflow.

100 people try it.

60 complete the workflow.

20 come back.

5 pay.

You learned something.

Now imagine launching with 25 different features.

People click everywhere.

Half never finish onboarding.

Some use one feature.

Others use another.

Nobody pays.

What exactly did you learn?

More software does not automatically produce more information.

Often it produces less.

That's why I like this loop:

small build → real user → clear signal → next decision

AI makes that cycle dramatically cheaper.

And that's where I think its real advantage is.

The smartest builder might build less

We've spent a lot of time measuring AI development tools by output.

How much code can they generate?

How many screens?

How quickly?

How many integrations?

Those things matter.

But maybe there's another benchmark:

How much unnecessary product did the tool help you avoid building?

That's harder to show in a demo.

But for someone actually trying to create a business, it might be much more valuable.

The future of AI app building shouldn't only be:

“Tell me what you want and I'll build it.”

It could also be:

“Before we build that — do you actually need it yet?”

And strangely enough, the AI builder that occasionally tells you no might end up helping you ship faster.

The AI App Builder Problem Nobody Talks About: What Happens After Launch?

altuntas gokcer — Mon, 21 Sep 2026 12:09:07 +0000

AI app builders have gotten really good at the beginning.

Describe an idea.

Generate a few screens.

Connect some data.

Add authentication.

Deploy.

And suddenly you have something that looks like a real product.

That part is impressive.

But I think we're starting to optimize for the wrong milestone.

Getting an app online isn't the end of the hard part.

For most products, it's where the useful questions finally begin.

Launch gives you answers your prompt never could

Before launch, almost everything is an assumption.

You think users will understand the onboarding.

You think feature A matters more than feature B.

You think the pricing page makes sense.

You think people will use the workflow the way you designed it.

Then real users arrive.

And they do something completely different.

They stop halfway through onboarding.

They ignore the feature you spent three days polishing.

They repeatedly use something you considered a minor detail.

They come from a marketing channel you didn't expect.

This is the moment where the app becomes interesting.

Because now you have signal.

This is where many AI builders stop too early

A lot of the conversation around AI development still looks like this:

idea → prompt → generated app → deploy

But a real product looks more like:

idea → build → launch → observe → change → repeat

That second half matters just as much as the first.

If users are abandoning the product after signup, generating another feature probably isn't the answer.

If one acquisition channel sends users who actually stick around while another sends hundreds of empty visits, that's useful information.

If customers repeatedly ask for the same workflow change, that should influence what gets built next.

An app builder that disappears after deployment is only solving part of the problem.

The interesting AI isn't just the AI that writes code

Imagine your product has been live for two weeks.

Instead of only asking:

Add another dashboard.

What if your product environment could help surface something more useful?

For example:

Most users who complete onboarding use feature X within their first session.

Or:

Traffic from channel A converts better than channel B.

Or:

Users keep abandoning this step.

Now the next product decision has context.

That's much more interesting to me than generating another page because someone typed another prompt.

This is something we're thinking about at built.new

Full disclosure: I'm involved with built.new.

One of the ideas behind what we're building is that creating the application shouldn't be the entire experience.

The product still has to be launched.

It has to reach people.

You need to understand what happens after those people arrive.

And then you need to improve it.

That means thinking beyond just:

“Can AI generate this?”

and toward:

“Can AI help me move from an idea to a product that actually improves from real-world feedback?”

The direction is closer to:

plan → build → ship → measure → improve

And potentially marketing becomes part of that same loop too.

Because product decisions and distribution decisions aren't completely separate.

If a channel brings the right users, that's product information.

If users repeatedly abandon one workflow, that's product information.

The app itself is only one part of that system.

Deployment should be the beginning of the second loop

AI has dramatically reduced the time it takes to create something.

That's great.

But the next big improvement probably isn't making the first generation another 30 seconds faster.

It's shortening the distance between:

user behavior → useful insight → product change

If AI builders can help with that loop, they stop being code-generation tools.

They start becoming something closer to a product-building environment.

And I think that's a much more interesting future.

Shipping is no longer the finish line. It's where the real product decisions begin.

AI Can Build Your MVP. But Can It Help You Decide What to Build Next?

altuntas gokcer — Sat, 19 Sep 2026 13:02:22 +0000

Building the first version of an app is getting ridiculously fast.

You can describe an idea, wait a few minutes, and get something that already looks like a product.

That’s great.

But I think we’re starting to focus on the wrong part of the process.

The hard question is no longer just:

Can AI build this?

It’s:

What should we build first, what should we leave out, and what should we change after real users arrive?

The first prompt is not the product

Imagine you want to build a booking app for a small business.

It’s very easy to start adding things:

accounts
staff roles
payments
analytics
notifications
loyalty
admin tools
AI recommendations

And technically, AI might be able to generate all of them.

But that doesn’t mean version one needs them.

The actual first question might simply be:

Will customers use this instead of booking manually?

If you can answer that with one small workflow, everything else can wait.

That’s why I think the next generation of AI app builders needs to do more than generate features.

It needs to help with the decisions around them.

Before building, decide what actually belongs in version one

This is something we’re working on with built.new.

Full disclosure: I’m involved with the project.

The workflow doesn’t begin with “generate my app.”

It begins with questions.

Who is this for?

What does the user absolutely need to do on day one?

What can wait?

Who pays?

Then the product is planned screen by screen before the build starts.

And sometimes the useful answer is:

You don’t need that feature yet.

I think that matters more than it sounds.

When generating software becomes cheap, restraint becomes a product feature.

Build is only step one

The other thing I think AI app builders get wrong is where they stop.

A generated app is not automatically a business.

Once the product is live, you still need to know:

Are people using it?

Where are they dropping off?

Which users are converting?

Which marketing channels are actually working?

What should you change next?

That’s why built.new is designed around a longer loop:

plan → build → ship → measure → market → improve

The app is one part of the system.

The feedback loop around the app is what turns it into a product.

Imagine the builder seeing what happens after launch

Take a simple booking business.

The useful output isn’t only:

Your booking app is live.

It could also be:

Saturday appointments fill first.

This ad generated bookings. This one didn’t.

New customers are dropping before payment.

Should we add a deposit to first bookings?

That’s a much more interesting role for AI.

Not just generating another screen.

Helping you understand what the business is telling you.

The prompt shouldn’t be the end of the conversation

There’s another problem with the “one prompt → app” idea.

Products change constantly.

Someone uses the app and asks for something.

A workflow turns out to be confusing.

A feature nobody expected becomes important.

So instead of treating the generated project as finished, I think the builder should stay part of the product loop.

You should be able to come back and say:

“Add a deposit for first-time bookings.”

“Customers keep asking for evening slots. Change the booking flow.”

And continue from the product you already have.

That’s much closer to how real software is built anyway.

Maybe the real product is the loop

AI has already made the distance between an idea and a first build much shorter.

The next challenge is shortening this distance:

idea → plan → product → users → signal → better product

That’s the direction I find much more interesting.

Because the winner in AI app building probably won’t be the tool that generates the most features from one prompt.

It’ll be the one that helps someone with an idea keep making better decisions after the first prompt is over.

Would you rather have an AI builder that generates more features, or one that helps you decide what to build next?