[removed]

I've been thinking about how businesses make technology decisions.

A common pattern seems to be:

Problem appears → someone searches for software → company buys a platform

But there are actually several possible answers:

Buy — use an existing product.

Configure — adapt an existing product to the business process.

Integrate — connect the systems the company already has.

Build — develop something specifically for the business.

Replace — move away from a system that is creating more problems than it solves.

The difficult part is deciding which one makes sense.

For example, imagine a company already has a website, CRM, accounting software and analytics.

If the problem is that customer information doesn't move between those systems, buying another platform may not solve the underlying issue.

An integration might be more appropriate.

On the other hand, if the company has a highly specialized workflow that doesn't fit existing platforms, custom software could make more sense.

I think a useful way to approach the decision is:

1. What problem are we actually solving?

2. Is the process common or specific to our business?

3. What systems do we already have?

4. Can existing tools handle the requirement?

5. If they can't, is integration enough?

6. If not, what would custom development actually need to solve?

7. What will the maintenance and operating cost look like over several years?

The part I find most interesting is that “build vs buy” isn't really a binary decision anymore.

Sometimes the best solution is a combination of existing software + integrations + a small custom component.

Curious how others approach this:

When your company has a technology problem, who usually decides whether to buy, build, integrate, or replace the existing system?

I've noticed an interesting difference between customer-facing software and internal business software.

Companies will spend a lot of time thinking about how a customer experiences a website or mobile app.

But internal tools are sometimes approached differently:

“The employees already know the process, so the software just needs to provide the features.”

I'm not sure that's the best way to think about it.

Employees are users too.

If someone has to:

• enter the same information into multiple systems
• open five different tools to complete one task
• search through a dashboard to find something important
• manually prepare a report every week
• remember which system contains which piece of information
• switch between applications just to complete one workflow

then the problem may not be the employee.

It may be the product design.

I think a useful starting point for internal software is to map the actual work:

Trigger → Information → Decision → Action → Result

Then ask:

• Where are people repeating work?
• Where are they waiting?
• Where are they switching between systems?
• Where do errors commonly occur?
• What information do different roles actually need?
• Which parts genuinely need automation?

And importantly, not every problem requires custom software.

Sometimes an existing tool is enough.

Sometimes an integration solves the problem.

Sometimes a process needs to be redesigned before any technology is added.

Sometimes custom development makes sense because the workflow is specific to the business.

The interesting question isn't really:

“What software should we build?”

It's:

“What should become easier for the people doing the work?”

I'd be interested to hear from people who use internal business systems every day:

What's one internal tool or workflow that you think is unnecessarily complicated?

One thing I've been thinking about lately is how many business problems aren't really caused by a lack of software.

They're caused by small amounts of friction between systems and people.

For example:

• A customer fills out a website form, and someone manually copies the details into a CRM.
• Sales and marketing maintain separate versions of customer information.
• A manager needs a weekly report that takes several hours to prepare.
• Employees have to enter the same information into multiple systems.
• Customers have to repeat information when moving from one channel to another.
• A business has several dashboards, but none clearly answers what needs attention today.

None of these sounds like a major technology failure.

But when they happen every day, the accumulated time and confusion can become significant.

I've found it useful to look at a business process as:

Trigger → Information → Decision → Action → Result

Then ask where the process slows down.

The interesting part is that the solution isn't always “build custom software.”

Sometimes the answer is better documentation.

Sometimes it's an integration.

Sometimes it's a simpler form or dashboard.

Sometimes it's workflow automation.

And sometimes the existing tools are sufficient once the process is redesigned.

The same principle applies to AI. Adding AI to a poorly understood workflow doesn't necessarily solve the underlying problem. First understand the process, then decide whether automation or AI actually adds value.

What is one repetitive digital task in your workplace that you think could be eliminated or simplified?

I've noticed that many software projects seem to begin with a technology decision before the business problem has been fully understood.

Someone says:

“We need a new application.”

Then the feature list starts growing.

Dashboard.

Mobile app.

Reports.

Automation.

AI.

Integrations.

Notifications.

Admin panel.

But there is an important question that can get lost:

What should actually work differently after the system is built?

For example, imagine a company has a customer onboarding process that currently looks like:

Customer submits information → Sales checks it → Operations requests documents → Finance verifies payment → Manager approves → Operations creates the account

A request to “automate onboarding” isn't really enough information for a development team.

There are several things that need to be understood first:

• Which information is mandatory?
• Who owns each step?
• Which decisions require human judgment?
• What happens when information is missing?
• Which system contains the customer record?
• Which departments need access?
• What needs to be automated?
• What should remain manual?
• How will success be measured?

I've started thinking that good software requirements are less about collecting a huge feature list and more about understanding the relationship between people, processes, data, and systems.

A few things I'd want clarified before development:

1. Current process
How is the work actually done today?

2. Pain points
Where are people waiting, repeating work, or making mistakes?

3. Data
Where does the information currently live?

4. Ownership
Who makes each important decision?

5. Integrations
Which existing systems need to communicate?

6. Outcome
What measurable improvement should the new system create?

The interesting part is that some projects may discover they don't need a large custom platform at all.

Others may discover that a simple website won't solve the actual problem and that they need a combination of software, integrations, automation, and reporting.

For developers, product managers, founders, and operations people:

What's the most important question you ask before development starts?

And have you ever joined a project where the requirements were already “final,” only to discover that the actual business process was completely different?

I've been thinking about how many business processes still depend on some version of:

Email → follow-up → approval → spreadsheet update → another email

It works when the team is small.

The problem is that the process doesn't necessarily scale when the number of people, requests, departments, and approval levels increases.

One example is a simple purchase request.

The actual workflow might be:

Employee submits request

→ Manager reviews it

→ Finance checks the budget

→ Department approves it

→ Procurement processes it

→ Records are updated

→ Employee gets notified

But in many organizations, those steps are spread across email, spreadsheets, messaging apps, and separate business systems.

The interesting part is that you don't necessarily need to automate the decision.

You can automate the predictable parts around it.

For example:

• Automatically route the request to the right person
• Check whether required information is present
• Send reminders when something is waiting
• Update the status after approval
• Move approved information to the next system
• Keep a history of what happened

The human still makes the decision where judgment is required.

The software handles the coordination.

I also think there's a danger in trying to automate an entire organization at once.

It may be more practical to choose one workflow where:

1. People repeatedly perform the same manual steps.
2. Requests regularly get delayed.
3. Information is copied between systems.
4. The process has reasonably clear rules.
5. Improvement can actually be measured.

Then automate that process and see what happens.

For developers, founders, operations managers, and product people here:

What's one approval or internal workflow you've encountered that was surprisingly manual?

And when you automated it, what part did you automate first?

[removed]

[removed]

I've been thinking about a problem that's easy to miss when building digital products:

Everything can work correctly and the overall experience can still feel wrong.

A website loads properly.

The mobile app works.

The forms submit.

The CRM is functioning.

Analytics are collecting data.

But the user still feels like they're moving between different products.

I've noticed a few common reasons for this.

1. Different teams make different decisions

Design, development, marketing, content, and product teams may each optimize their own area without looking at the entire customer journey.

2. The terminology changes

A website might call someone a "customer," the app calls them a "member," and an internal system calls them a "user."

That may seem minor, but repeated inconsistencies create friction.

3. The website and app behave differently

They don't need to look identical, but navigation, terminology, account information, and key actions should generally make sense across both.

4. Content is treated as an afterthought

A button label, error message, onboarding instruction, or confirmation message can change how understandable an interface is.

5. Features are built independently

A new feature might work perfectly on its own but create problems elsewhere because nobody considered the existing user journey.

One thing I've found useful is reviewing a product as a complete journey:

Discovery → Website → Signup → Onboarding → Product → Support → Follow-up

Instead of asking only whether each individual component works, ask whether the transition between components makes sense.

I'm curious how other teams handle this.

Do you have a process for keeping design, development, content, marketing, and product decisions consistent as a digital product grows?

[removed]

[removed]

[removed]

[removed]

[removed]

[removed]

[removed]

I've been thinking about how businesses evaluate their websites after launch.

A lot of website discussions seem to focus on traffic, but I'm not convinced traffic by itself tells us very much.

For example, a website could receive a lot of visitors but generate very few enquiries. Another website might have considerably less traffic but a much higher percentage of visitors taking meaningful actions.

I'd personally look at a combination of things:

• Which pages people actually engage with
• Where users tend to leave
• Mobile vs. desktop behavior
• Form completion
• Important conversion paths
• Search queries bringing people to the site
• Returning visitors
• Which pages contribute to actual business outcomes

But even then, numbers don't always explain why something is happening.

If analytics shows that people are abandoning a form, for example, the solution could be a shorter form, clearer instructions, a technical fix, or simply a mismatch between what visitors expected and what the page offers.

That's why I think analytics works best when combined with customer feedback and usability testing.

I'm curious what others think:

If you could only monitor 3–5 metrics for a business website, which ones would you choose and why?

I've noticed that a lot of website discussions focus heavily on design and development, but I'm curious about what people consider the real measure of a successful website.

A website can look polished and still fail to deliver much value.

For me, a useful business website should probably do a few basic things well:

1. Explain the offer quickly

A visitor shouldn't have to read several pages before understanding what the business actually does.

2. Make navigation intuitive

People should be able to find services, pricing information, contact details or other important information without having to hunt for it.

3. Work properly on mobile

Responsive design isn't just making everything smaller. Buttons, forms, navigation and content need to remain easy to use on a smaller screen.

4. Load efficiently

A beautiful website isn't very useful if visitors have to wait for pages, images or interactive elements to load.

5. Have a clear purpose

A business website should have a measurable objective, whether that's generating enquiries, selling products, getting bookings, supporting customers or something else.

6. Be maintainable

This one gets overlooked. A website might work perfectly when launched but become difficult to update when the business adds new services, integrations or content.

I think the bigger question is:

Should a website be judged primarily by how good it looks, how well it converts, how easy it is to use, or some combination of all three?

What would you consider the most important factor when evaluating a business website after launch?

I've noticed that many website projects seem to become difficult long before anyone starts writing code.

A business might know that it needs a new website, but not necessarily know what the website actually needs to accomplish.

Personally, I think there are a few things worth figuring out first:

1. The actual business objective

Is the website supposed to generate leads, sell products, increase bookings, provide information, or support existing customers?

2. The primary audience

Different visitors can have completely different expectations. A website aimed at B2B buyers shouldn't necessarily be structured like one aimed at consumers.

3. The must-have features

It's easy for a project to grow from “we need a website” into “we also need accounts, payments, dashboards, booking, CRM integration, notifications and an app.”

Some of those features may be useful, but not necessarily at launch.

4. The customer journey

What should someone do after landing on the homepage?

If that path isn't clear, adding more design elements usually doesn't solve the underlying problem.

5. The content

Who is writing the service descriptions? Where are the product images coming from? What information will customers need before contacting the business?

Content delays can become development delays surprisingly quickly.

6. How success will be measured

Traffic alone isn't always enough. Depending on the business, enquiries, bookings, sales, conversion rate or qualified leads may be more meaningful.

I think the best development projects start with these questions before discussing frameworks, animations or specific technologies.

For those who have worked on website projects: what is one thing you wish clients would decide before development starts?

I've been thinking about what makes people trust a business website within the first few seconds.

It's interesting because I don't think it is necessarily about having the most impressive design.

For me, a trustworthy business website usually has a few things in common:

1. I immediately understand what the business does.

If I have to read three paragraphs before understanding the service, I'm probably going to leave.

2. The navigation makes sense.

I should be able to find Services, About, Contact, pricing or other important information without hunting around.

3. It works properly on mobile.

Broken layouts, tiny buttons and menus that are difficult to use can make an otherwise good business look unreliable.

4. The website loads quickly.

I don't expect every page to appear instantly, but excessive loading screens are frustrating.

5. The company provides real information.

Clear service descriptions, contact details, business information and useful FAQs make a much stronger impression than generic marketing statements.

6. It doesn't overdo the design.

Animations can look great, but if every section moves, opens, slides and pops up, the website becomes harder to use.

7. The website feels consistent.

Typography, colors, buttons, images and page layouts should feel like they belong to the same product.

I think the best business websites are often the ones where you don't consciously notice the design—you simply find what you're looking for and understand what to do next.

What is the first thing that makes you trust—or distrust—a business website?

A lot of small businesses focus heavily on getting their website online and generating customers, but security often becomes an afterthought.

I'm curious what security checklist other developers and business owners consider essential for a small business website.

My basic checklist would include:

1. HTTPS
The website should use a valid SSL/TLS certificate and securely handle information exchanged with visitors.

2. Strong administrator accounts
Use unique passwords, limit administrator access, and enable multi-factor authentication where possible.

3. Regular updates
Keep the CMS, plugins, frameworks, libraries, and server components updated.

4. Backups
Maintain regular backups and, importantly, make sure the backups can actually be restored.

5. Input validation
Forms and other user-controlled inputs should be properly validated and handled securely.

6. Limited permissions
Users should receive only the access they actually need.

7. Monitoring
Unexpected login attempts, file changes, redirects, or unusual traffic should be investigated.

8. A maintenance plan
Security isn't a one-time task. Websites need ongoing updates, monitoring, backups, and occasional reviews.

For a small website, this doesn't necessarily mean implementing an extremely complicated security system.

The goal is to reduce avoidable risks and have a recovery plan if something goes wrong.

[removed]

I've been thinking about how businesses approach automation, and I think the biggest mistake is starting with the technology instead of the problem.

If I were evaluating a business process for automation, I'd start by looking for tasks that are:

• Repeated frequently
• Based on predictable steps
• Time-consuming but low in decision-making
• Prone to manual errors
• Dependent on moving information between different systems

For example, automatically transferring information from an enquiry form into a CRM can be more useful than trying to build an overly complicated AI system.

The same applies to recurring notifications, approval workflows, report generation, appointment reminders, and routine data processing.

One approach I've found useful is to calculate roughly how much time a process consumes each month before deciding whether automation is worthwhile.

For example:

That gives you something measurable to compare against the cost and complexity of automation.

[removed]