News and articles. From real work, no fluff.
What we learn from client projects and our own products. SEO, AI, security and development.
Latest
App developmentNovember 6, 2026 · 9 min read
Customer development: How to run useful customer interviews
Before designing a product, we need to understand the situation it should improve. Customer interviews help us examine specific experiences, current workarounds and consequences. Praise for an idea does not provide a development brief.Read article →Mobile design for thumbs: Touch targets, spacing and reach
A mobile button must be easy to hit, distinguish from nearby actions and understand after a tap. We explain how to review touch targets from the design file to the working product.Your first App Store and Google Play release: a submission checklist
An app can work on a developer’s phone and still be far from a public release. You need the right accounts, a tested build, complete submission details and working access for the reviewer. This guide covers the first release on the App Store and Google Play, from assigning responsibilities to handling a rejection. Nobody can promise approval on the first attempt, but careful preparation can prevent avoidable delays.Adding a Mobile App to an Existing Web Product: What to Reuse and Redesign
You already run a web application or client portal, and customers want a convenient way to work from their phones. A mobile app can share accounts, data and some business rules with your existing product. First, decide which tasks belong on mobile, whether your current system can support them and how the two clients will work together.Product vision and strategy: give your team a shared direction
Product vision describes the change you want to create for customers. Strategy explains who you will serve, how you will help them and what takes priority. Their value becomes clear when the team faces competing requests. This guide shows how to establish a clear direction, turn it into decisions you can test and keep it useful in everyday work.Wireframes and interactive prototypes: Validate an idea before development
Before committing to development, test the weakest assumption in your design. A wireframe shows structure; an interactive prototype lets you observe a specific task. Neither proves demand or technical feasibility by itself. This guide walks through a brief, a test and a decision using a business purchase approval example.iOS or Android: How to choose your app’s first platform
Choose your first platform around the people who will actually use the app and the task it needs to support. The choice between iOS and Android affects pilot recruitment, technical constraints, testing and ongoing operations. Here is how to compare the evidence and select a first step that produces a useful answer.Web application performance: speed up the database, API and interface
To make a web application faster, first locate the time users actually lose, then change the part responsible for it. A slow screen might be waiting for a database query, an external API or JavaScript running in the browser. Each needs a different fix. This guide follows one user operation from click to usable result and explains what to measure, when indexes or caching help, and how to verify an improvement without hiding errors or sacrificing correct data.Scaling a growing application: a practical capacity plan
When an application is growing, scale the constraint you have measured and keep enough capacity for the busiest credible scenario. A rising account total alone cannot tell you what to buy. You need a view of peak demand, a service target, a tested operating limit and a decision about what happens if part of the system fails. This guide turns those inputs into a practical plan for product owners and technical teams, from the next campaign to the next investment.Does your online store need an app, or a better mobile website?
An ecommerce app earns its place when it makes a recurring customer task easier and creates more value than it costs to build and run. A high share of mobile traffic, or a competitor with an app, is not enough. This guide compares mobile websites, PWAs and store-distributed apps, with practical examples from repeat purchasing and B2B ordering. It also shows how to calculate a return without treating every order placed in the app as a new sale.How to choose a software development company: 20 questions to ask before you sign
Choose a custom software development company by its answers, not its pitch deck: who will actually work on your project, how the fixed price is set, who will own the code, who is responsible for your data, and what happens after launch. We put together 20 questions worth asking every vendor before you sign. For each one, you’ll find what a good answer looks like and what should worry you. Current as of October 17, 2026.How to choose a web application stack: React, Node.js and alternatives
One proposal promises React, another recommends Node.js and a third offers rapid development in Python. They may be describing different parts of the same system. Start with the work your users need to complete, test the biggest uncertainty and decide who will maintain the result.Mobile app accessibility: VoiceOver, TalkBack and larger text
The button is visible, but a screen reader cannot name it. Increasing the text size hides the order confirmation. Accessibility determines whether someone can finish a task independently. Test complete journeys on iPhone and Android with screen readers, larger text and alternative controls.UX metrics: How to use SUS, NPS, CSAT and task completion
The survey looks positive, but people still cannot complete an order. Each metric describes a different part of the experience. Here is when to use SUS, NPS, CSAT and task completion, how to calculate them and what the results can actually support.How to build a SaaS product: From an idea to your first 100 paying customers
Your application works and registrations are growing, yet paying customers remain scarce. Reaching the first hundred starts before development: choose a recurring problem, test willingness to pay and make the route to repeated value clear.Offline apps: When you need them and how synchronisation works
A salesperson drafts an order without internet access. Meanwhile, a colleague changes the price and reserves the last item. Reconnecting is not simply a matter of transferring both records. The app must decide what is valid, what needs confirmation and what requires a person’s judgement.20 UX rules to follow when designing a prototype
A prototype should help you decide whether people can complete an important task. Linking attractive screens is only part of that work. These 20 checks help you prepare a clear design, a useful test and a handover that exposes unresolved decisions.Mobile apps for field technicians: What needs to work offline
A technician records the parts used, photographs a repair and asks the customer to confirm the job report. There is no signal in the basement plant room. Back outside, the phone reconnects. The office needs the complete report, and the technician needs to know it has arrived. That is the real test of an app built for field work.Your AI-built app works. Is it ready for real customers?
The prototype runs through a demo and your first users want access. Before launch, check whether the application protects their data, completes orders correctly and can be maintained. Those findings will help you decide what to keep and what still needs work.Website and app handover: What to collect and how to check it
The site is live. But can your business update it, deploy a new release or recover its data without relying on the original supplier? A useful handover record shows what you have received and checked. Here is how to cover access, documentation, testing and ongoing responsibility.How to define an MVP without wasting the development budget
An MVP becomes expensive when every stakeholder interprets “minimum” differently. Sales expects a complete product, engineering plans for an unknown future and the founder keeps adding features that might help. A useful definition makes one learning objective, one usable journey and the spending decision explicit before the team commits to delivery.App Store Optimization: help the right users find your app
Your app solves a real problem, but its store page looks like a feature inventory. App Store Optimization starts by matching a user’s search and expectation to a credible product promise. Improve discovery, explain the value clearly and measure what happens after installation, rather than chasing a keyword position in isolation.Prioritize the backlog: use methods that explain the decision
The backlog contains a customer’s requested export, an onboarding improvement and a change that makes future integrations easier. Each has a different kind of value, and each stakeholder calls their item urgent. A useful prioritization method makes the tradeoff understandable and identifies what the team should do next.Gamification in everyday apps: reward useful progress
A training app can congratulate someone for completing a useful practice task or award points for repeatedly tapping through screens. Both designs look playful. Only one supports the reason the person opened the app. Good gamification connects a clear goal, an achievable challenge and feedback the user can trust.PWA or native app: choose around the work users need to do
A field technician needs to open a work order, record a repair and send it when connectivity returns. A home-screen icon is useful, but it does not answer whether the application can protect an unfinished report or reach the required equipment. Choose the platform around these jobs and the devices that must support them.Product analytics: find out what people actually do in your app
Your app has active accounts, but you cannot tell whether customers are reaching the result they came for. Product analytics connects recorded behavior with specific decisions: where onboarding fails, which features support repeat use and whether a change improves the experience.Push notifications: design campaigns that earn a return visit
A notification can remind someone to finish a useful task or make them wish they had never installed your app. The difference starts before the copy: decide who needs the message, what has changed, how long it remains useful and what would justify interrupting that person.Payments in apps: connect Stripe, GoPay and subscription billing correctly
A customer pays, closes the browser before returning to the app, and receives no access. Another refreshes the success page and triggers duplicate fulfillment. A dependable payment integration must work through delayed results, repeated notifications, failures, and changes after the initial checkout.Dashboard design: make complex data useful for the next decision
An operations manager opens a dashboard filled with charts, yet still asks which requests need attention today. The screen contains data, but it does not support the decision. Good dashboard design connects a user's question to relevant evidence and a practical next step.How to scale a product team without slowing delivery
You add developers to clear the roadmap, but features spend longer waiting for decisions, reviews, and shared environments. Everyone is busy while completed work barely moves. Growing a product team requires more than dividing the backlog: the way people decide, build, release, and support the product must grow with them.When does your product need a design system?
Three teams ship three versions of the same form. Each looks acceptable in isolation, but labels, errors, spacing, and keyboard behavior differ. The next change must be repeated everywhere. A design system becomes useful when it gives these repeated decisions a shared home and a reliable path into the product.Maps and geolocation in apps: the pitfalls behind the pin
A map pin looks simple. Behind it sit device permissions, uncertain coordinates, third-party services, licensing rules, and decisions about personal data. A nearby-store search needs a different design from live delivery tracking. Getting that distinction right early can prevent a small feature from becoming an expensive operational problem.Agile vs. waterfall: which approach fits your software project?
One team needs to discover what customers will actually use. Another must move an ERP system during a carefully scheduled shutdown. Both need good software, but they face different uncertainties. Agile and waterfall help organize those uncertainties in different ways. The useful question is which decisions you can safely make now and which need evidence first.User Onboarding: How to Stop Losing New Users in the First Few Minutes
A new user signs up, swipes through three welcome screens, gets asked for location and notifications, and lands on an empty dashboard. A minute later they are gone for good. Every one of those steps was designed with good intentions. Together, they stand between the user and the reason they opened your app in the first place. We pulled together research from Apple, Google, Microsoft, Nielsen Norman Group and the EU to show what actually helps in the first minutes after sign-up, and what just gets in the way.PostgreSQL, MySQL or NoSQL? How to choose a database you won’t have to replace in three years
Choosing a database is one of those decisions that takes an afternoon at the start of a project and then stays with you for years. Switching databases under a live application is a major project, as the Guardian, Uber and Discord all found out. We compared PostgreSQL, MySQL and the best-known NoSQL databases using current survey data, price lists and documentation as of September 29, 2026. We also cover where your data physically lives and what the GDPR requires.App Notifications and Emails That Don’t Annoy: How to Set Them Up So the Important Ones Still Get Through
When an app pings too often or about things that don’t matter, people switch its notifications off and start deleting its emails unread. Then the one message that does matter, like a suspicious sign-in alert, never reaches them. Below: how to pick the right channel and set frequency caps and quiet hours, what Apple, Google, Yahoo and Microsoft actually require, and where a service message ends and marketing begins under EU and US law.How to Stop Users From Deleting Your App After a Week: Push Notifications and Retention That Work
Seven days after install, only seven to ten people in a hundred open a typical app. By day 30 it’s three or four. Most of that is decided at the very start: whether people understand within a minute what the app does for them, when and why you ask for notification permission, and whether the messages that follow are ones they actually want. Here are the global numbers, Apple’s and Google’s rules, what EU law expects and a concrete plan for a new user’s first month.Web app scalability: how to prepare your system for hundreds of thousands of users
A web app can handle hundreds of thousands of users if you first measure where the bottleneck is and only then add capacity. It is rarely a weak server. Far more often it is the database, a slow third-party service or thousands of people arriving in the same minute. We walk through real outages, a government load test that published every number, and how Notion, Figma and Shopify grew, then finish with a plan for 1,000, 10,000 and 100,000 users.Mobile app updates after launch: versioning, release strategy and the 2026 Apple and Google deadlines
A mobile app that nobody updates after launch will eventually become impossible to update and hard for new users to find in the store. Apple and Google raise their minimum requirements every year, each new version of iOS and Android changes how phones behave, and your users all update at a different pace. Here is what 2026 demands, how to number your versions, how to release in stages, what to monitor after a release and when forcing an update actually makes sense.UX design for web apps: why users come back and why they leave
People leave a web app because they can’t tell what it’s for in the first few minutes, because a slow or confusing interface gets in their way, and because they hit an error with no way forward. They come back to apps that let them do what they came for quickly, again and again. Here’s what data from the EU and from more than 10,600 digital products says about it, and how to find out where your own users drop off.App monetization models: subscriptions, in-app purchases or ads?
For apps people use regularly, subscriptions are usually the most reliable way to earn. In-app purchases work when users pay for something specific, and ads only pay off once an app has a really large audience. Many of the most successful apps combine all three. Here is how much of the price you actually keep after Apple and Google take their share, what numbers to expect, and how to pick the right model.How to plan SaaS development: from the first wireframe to launch
The most expensive mistakes in a SaaS project are made in the plan, not in the code. A subscription app that many companies use at once has to handle, from day one, things an ordinary website never has to deal with: teams and roles, payments, separated customer data and uptime. Here is the path from the first wireframe to launch, step by step, with a timeline, a budget and a checklist.Native vs. cross-platform app development: what actually pays off for your project in 2026
For most business apps, cross-platform development is the better deal today: one codebase for iPhone and Android, one team, and roughly half the work on every new feature. Native development earns its cost when the app depends on raw performance, phone hardware or the very latest iOS and Android features. Here is how to tell which group your app belongs to.From Idea to MVP: How to Validate Demand for Your Web App Before You Build It
The most expensive mistake in app development isn’t bad code. It’s building an app nobody wants. Here’s how to test demand in six weeks for a few hundred dollars, before you sign a development contract.Share this page
Got an idea?
On a short call, we'll find out what you need and suggest the next step. Then you'll get a proposal with a fixed price and a timeline.
+420 771 166 199Mon to Fri, 8:30 a.m. to 4:00 p.m. (Prague time) · info@listify.coolWhen should we call you?
Pick a day and a time window. We'll call you, and it takes about 15 minutes.
Day