[{"data":1,"prerenderedAt":532},["ShallowReactive",2],{"blog-list-en":3},[4,140,291,421,497],{"id":5,"title":6,"author":7,"body":8,"cover":123,"description":124,"extension":125,"featured":126,"meta":127,"navigation":128,"path":129,"publishedAt":130,"readingTime":131,"seo":132,"stem":133,"tags":134,"__hash__":139},"blogEn\u002Fblog\u002Fen\u002Fchoose-web-app-technology.md","How to Choose Technology for a Web Application: A Practical Guide for Businesses","Kamil Bartczak",{"type":9,"value":10,"toc":114},"minimark",[11,15,18,23,26,29,48,51,55,58,61,64,68,71,74,78,81,84,88,91,111],[12,13,14],"p",{},"Choosing technology for a web application is not a contest for the newest framework. It is a product decision that affects delivery speed, reliability, maintenance cost, and the team's ability to make changes after launch.",[12,16,17],{},"The best stack is usually the one that fits the problem well and lets the team move with confidence. It should support the first release without making future work unnecessarily difficult.",[19,20,22],"h2",{"id":21},"begin-with-product-constraints","Begin with product constraints",[12,24,25],{},"Technology choices become clearer when the product constraints are visible. A public marketing site, a customer portal, an internal operations tool, and a real time marketplace may all need a web interface, but they create different technical priorities.",[12,27,28],{},"Start with questions such as:",[30,31,32,36,39,42,45],"ul",{},[33,34,35],"li",{},"Is the application public, private, or both?",[33,37,38],{},"Does it need strong search visibility and fast first page load?",[33,40,41],{},"Will users work with complex forms, data tables, or live updates?",[33,43,44],{},"Are there existing services or databases that must be integrated?",[33,46,47],{},"How often will the product change after launch?",[12,49,50],{},"These answers matter more than a list of popular technologies.",[19,52,54],{"id":53},"match-the-frontend-to-the-experience","Match the frontend to the experience",[12,56,57],{},"For many web products, Vue and TypeScript provide a productive combination for building clear, maintainable interfaces. Vue supports component based development without forcing unnecessary complexity. TypeScript makes data and application states easier to reason about, especially as the product grows.",[12,59,60],{},"Nuxt is a good fit when a project benefits from server side rendering, static generation, a structured routing system, or strong SEO foundations. It can serve both content focused websites and authenticated web applications, while keeping the development experience consistent.",[12,62,63],{},"The right choice still depends on the team and the product. A new framework is not automatically an upgrade if it slows down the people who need to maintain the system.",[19,65,67],{"id":66},"treat-the-backend-as-a-product-boundary","Treat the backend as a product boundary",[12,69,70],{},"The backend is responsible for more than storing data. It manages business rules, permissions, integrations, and the parts of the application that should not depend on a browser.",[12,72,73],{},"For an MVP, the backend should be simple enough to understand and deploy, while clearly separating important business logic from the user interface. A typed API, reliable database migrations, and basic observability often create more long term value than a complex microservice setup.",[19,75,77],{"id":76},"consider-maintenance-from-the-first-decision","Consider maintenance from the first decision",[12,79,80],{},"Every technical choice has an ongoing cost. This includes updates, security patches, cloud services, documentation, and the time needed for a new developer to understand the codebase.",[12,82,83],{},"A maintainable application usually has a small number of well understood technologies, automated checks, clear deployment steps, and sensible boundaries between modules. This is especially important for custom software that may evolve for years.",[19,85,87],{"id":86},"a-technology-selection-checklist","A technology selection checklist",[12,89,90],{},"Use this checklist when comparing options:",[30,92,93,96,99,102,105,108],{},[33,94,95],{},"Does the technology support the main user journey without unusual workarounds?",[33,97,98],{},"Can the current team deliver and maintain it confidently?",[33,100,101],{},"Does it meet the security, performance, and search requirements of the product?",[33,103,104],{},"Are hosting and external service costs appropriate for the current stage?",[33,106,107],{},"Is there a clear path to add integrations and features later?",[33,109,110],{},"Will the codebase remain understandable when the original team changes?",[12,112,113],{},"Good technology choices rarely make a product successful on their own. They create the conditions for a team to learn quickly, deliver reliably, and keep improving the product once real users arrive.",{"title":115,"searchDepth":116,"depth":116,"links":117},"",2,[118,119,120,121,122],{"id":21,"depth":116,"text":22},{"id":53,"depth":116,"text":54},{"id":66,"depth":116,"text":67},{"id":76,"depth":116,"text":77},{"id":86,"depth":116,"text":87},"\u002Fimages\u002Fblog\u002Fchoose-web-app-technology.avif","A business focused guide to choosing web application technology based on product needs, delivery speed, maintenance, and team capability.","md",false,{},true,"\u002Fblog\u002Fen\u002Fchoose-web-app-technology","2026-08-22","7 min read",{"title":6,"description":124},"blog\u002Fen\u002Fchoose-web-app-technology",[135,136,137,138],"Web application technology","Vue","Nuxt","TypeScript","NHIzJA66u2EPW3hqxfPlBq1PV_MsvP92E6N0_22bJKE",{"id":141,"title":142,"author":7,"body":143,"cover":279,"description":280,"extension":125,"featured":126,"meta":281,"navigation":128,"path":282,"publishedAt":130,"readingTime":283,"seo":284,"stem":285,"tags":286,"__hash__":290},"blogEn\u002Fblog\u002Fen\u002Fplan-web-app-mvp.md","How to Plan an MVP Web Application That Solves a Real Business Problem",{"type":9,"value":144,"toc":272},[145,148,151,155,158,161,164,168,171,178,181,196,199,203,206,209,226,229,233,236,239,242,246,249,269],[12,146,147],{},"An MVP is not a smaller copy of the final product. It is the shortest useful path between a business problem and evidence that the proposed solution works.",[12,149,150],{},"That sounds simple, but projects often become expensive before development starts. A long list of features is treated as a plan, teams start discussing tools before agreeing on the user problem, and success is reduced to launching on a particular date. A well planned MVP web application creates a different kind of clarity. It gives the team a focused first release, a way to measure its value, and enough technical structure to learn without creating unnecessary overhead.",[19,152,154],{"id":153},"start-with-the-problem-not-the-feature-list","Start with the problem, not the feature list",[12,156,157],{},"The first useful conversation is not \"what screens do we need?\" It is \"what is difficult, slow, risky, or expensive for the user today?\"",[12,159,160],{},"For example, a property business might ask for a client portal. The request can easily grow into profiles, notifications, file sharing, payments, analytics, and a mobile app. The first problem may be much narrower: prospective buyers wait too long for reliable information about availability. In that case, the MVP could focus on one flow: finding a unit, seeing current details, and sending an enquiry that reaches the right person.",[12,162,163],{},"This framing helps everyone reject features that sound attractive but do not improve the core outcome.",[19,165,167],{"id":166},"define-one-valuable-user-journey","Define one valuable user journey",[12,169,170],{},"An MVP needs one primary journey that a real person can complete from start to finish. It should include a clear trigger, a meaningful action, and a visible result.",[12,172,173,174],{},"A good starting question is: ",[175,176,177],"strong",{},"what must a user be able to achieve on their first successful visit?",[12,179,180],{},"For a B2B web application, that journey could be:",[182,183,184,187,190,193],"ol",{},[33,185,186],{},"A team member signs in.",[33,188,189],{},"They submit a request with the information the business needs.",[33,191,192],{},"The right colleague receives and processes it.",[33,194,195],{},"The requester can see what happened next.",[12,197,198],{},"Everything outside this path is not automatically excluded. It simply has to earn its place by making the first workflow safer, faster, or easier to understand.",[19,200,202],{"id":201},"set-success-criteria-before-implementation","Set success criteria before implementation",[12,204,205],{},"Without a measurable outcome, it is hard to know whether the MVP was a success or just a release. The metric does not need to be complicated. It needs to reflect a decision the business can make later.",[12,207,208],{},"Depending on the product, this might be:",[30,210,211,214,217,220,223],{},[33,212,213],{},"the percentage of users who complete the key flow,",[33,215,216],{},"the time saved on a manual process,",[33,218,219],{},"the number of qualified enquiries,",[33,221,222],{},"the reduction in errors or duplicated work,",[33,224,225],{},"the number of teams willing to use the product again.",[12,227,228],{},"The measure should be paired with a baseline whenever possible. If a process currently takes two days, a goal to reduce it to a few hours is more useful than a vague ambition to make it \"better\".",[19,230,232],{"id":231},"surface-constraints-early","Surface constraints early",[12,234,235],{},"Strong MVP planning does not ignore technical and operational constraints. It makes them visible before they become expensive surprises.",[12,237,238],{},"Discuss data sensitivity, required integrations, user roles, approval steps, legal obligations, and the expected pace of change. These topics influence the architecture, but they do not always require a large system from day one. A small application can still have clear access control, backups, logs, and a reliable deployment process.",[12,240,241],{},"The goal is to make a deliberate tradeoff. For example, a manual export might be acceptable for the first release if it validates demand. A missing audit trail might not be acceptable if the workflow handles regulated data.",[19,243,245],{"id":244},"a-practical-mvp-planning-checklist","A practical MVP planning checklist",[12,247,248],{},"Before development begins, a client and delivery team should be able to answer these questions:",[30,250,251,254,257,260,263,266],{},[33,252,253],{},"Who is the first user and what job are they trying to complete?",[33,255,256],{},"What is the smallest end to end flow that creates value?",[33,258,259],{},"Which information must be stored, and who can access it?",[33,261,262],{},"Which integrations are necessary for the first release?",[33,264,265],{},"What result will show that the product is worth improving?",[33,267,268],{},"Which assumptions are still risky enough to test before building more?",[12,270,271],{},"When those answers are clear, development becomes much calmer. The team can build a web application that is useful now, while preserving a clean path for the next decision.",{"title":115,"searchDepth":116,"depth":116,"links":273},[274,275,276,277,278],{"id":153,"depth":116,"text":154},{"id":166,"depth":116,"text":167},{"id":201,"depth":116,"text":202},{"id":231,"depth":116,"text":232},{"id":244,"depth":116,"text":245},"\u002Fimages\u002Fblog\u002Fplan-web-app-mvp.avif","A practical framework for planning an MVP web application: from discovery and scope to measurable outcomes and technical risk.",{},"\u002Fblog\u002Fen\u002Fplan-web-app-mvp","6 min read",{"title":142,"description":280},"blog\u002Fen\u002Fplan-web-app-mvp",[287,288,289],"MVP development","Web applications","Product strategy","y4-whE1n_nXGIQYWAKMKPxvBAbjDTEWB0OFkHhwDzPA",{"id":292,"title":293,"author":7,"body":294,"cover":410,"description":411,"extension":125,"featured":126,"meta":412,"navigation":128,"path":413,"publishedAt":130,"readingTime":283,"seo":414,"stem":415,"tags":416,"__hash__":420},"blogEn\u002Fblog\u002Fen\u002Fweb-app-development-cost.md","How Much Does Web Application Development Cost? Scope and Budget Factors",{"type":9,"value":295,"toc":402},[296,299,302,306,309,312,315,319,322,325,339,342,346,349,352,356,359,362,366,369,372,376,379,399],[12,297,298],{},"The cost of web application development is rarely determined by the number of screens alone. Two products can look similar in a presentation and require very different amounts of work once you consider who uses them, what data they manage, and what needs to happen behind the interface.",[12,300,301],{},"The useful question is not \"what is the fixed price for an app?\" It is \"what decisions create the scope, and how can we make those decisions with confidence?\"",[19,303,305],{"id":304},"scope-is-the-first-cost-driver","Scope is the first cost driver",[12,307,308],{},"Every feature has a visible part and an invisible part. A simple dashboard may need sign in, permissions, error handling, data validation, empty states, mobile behaviour, and reporting. A booking form may also need availability rules, confirmation messages, cancellation logic, and integration with another system.",[12,310,311],{},"This does not mean that a small product is a bad idea. It means the scope should describe outcomes, not just pages. Instead of asking for \"an admin panel\", define the decisions an administrator needs to make and the information they need to make them safely.",[12,313,314],{},"Clear scope helps distinguish a necessary first release from work that can wait until there is evidence that users need it.",[19,316,318],{"id":317},"user-roles-and-permissions-matter-early","User roles and permissions matter early",[12,320,321],{},"A web application becomes more complex when different users can see, edit, approve, or export different information. This is common in internal tools, customer portals, and B2B products.",[12,323,324],{},"It is worth listing roles at the start:",[30,326,327,330,333,336],{},[33,328,329],{},"What can a visitor do without signing in?",[33,331,332],{},"What can a regular user create or change?",[33,334,335],{},"Who can approve, delete, or access sensitive data?",[33,337,338],{},"Does anyone need an audit trail or a history of changes?",[12,340,341],{},"Answering these questions early prevents a common problem: building a simple workflow and later rebuilding large parts of it to introduce access control.",[19,343,345],{"id":344},"integrations-can-change-the-estimate-quickly","Integrations can change the estimate quickly",[12,347,348],{},"An integration is more than a button that connects two services. It needs authentication, error handling, data mapping, testing, monitoring, and a plan for changes on the other side.",[12,350,351],{},"Payments, accounting systems, CRM tools, maps, email providers, and AI services can all be valuable. They should be evaluated by the value they add to the first workflow. If an integration removes manual work or makes the product viable, it belongs in the MVP. If it only makes a future scenario more convenient, it may be better to postpone it.",[19,353,355],{"id":354},"quality-is-part-of-the-product-not-a-final-phase","Quality is part of the product, not a final phase",[12,357,358],{},"Reliable applications need more than their happy path. Users need useful feedback when data is loading, an action fails, or a list is empty. Teams need a way to deploy safely, restore data, and understand what went wrong.",[12,360,361],{},"The level of quality should match the product's risk. A prototype shown to a small group has different needs from a customer portal that handles personal data. The important part is making that difference explicit rather than quietly omitting quality work from the estimate.",[19,363,365],{"id":364},"include-the-cost-of-running-the-application","Include the cost of running the application",[12,367,368],{},"Development is only one part of ownership. A realistic budget also considers hosting, domains, external service fees, maintenance, monitoring, support, and future changes.",[12,370,371],{},"A thoughtful technical setup can keep those costs proportional to the product stage. An MVP does not always need enterprise scale infrastructure, but it should have a dependable backup strategy and a clear path for growth.",[19,373,375],{"id":374},"questions-that-make-a-budget-conversation-useful","Questions that make a budget conversation useful",[12,377,378],{},"Before asking for an estimate, prepare answers to these questions:",[30,380,381,384,387,390,393,396],{},[33,382,383],{},"What problem should the application solve first?",[33,385,386],{},"Who will use it, and what roles do they have?",[33,388,389],{},"Which process should become faster, safer, or easier to measure?",[33,391,392],{},"Which external systems must be connected from day one?",[33,394,395],{},"What data needs protection or a record of changes?",[33,397,398],{},"What needs to happen after launch: support, maintenance, or regular iteration?",[12,400,401],{},"The more clearly a business can explain the first outcome, the easier it is to build a sensible scope and a budget that supports it.",{"title":115,"searchDepth":116,"depth":116,"links":403},[404,405,406,407,408,409],{"id":304,"depth":116,"text":305},{"id":317,"depth":116,"text":318},{"id":344,"depth":116,"text":345},{"id":354,"depth":116,"text":355},{"id":364,"depth":116,"text":365},{"id":374,"depth":116,"text":375},"\u002Fimages\u002Fblog\u002Fweb-app-development-cost.avif","Understand the main factors behind web application development cost, including scope, integrations, user roles, quality, and long term maintenance.",{},"\u002Fblog\u002Fen\u002Fweb-app-development-cost",{"title":293,"description":411},"blog\u002Fen\u002Fweb-app-development-cost",[417,418,419],"Web development cost","Custom software","Project planning","cowgy3ilan2kXKrmKirNWP6q7uWjviZbXOM-drTjgQU",{"id":422,"title":423,"author":424,"body":425,"cover":485,"description":486,"extension":125,"featured":128,"meta":487,"navigation":128,"path":488,"publishedAt":489,"readingTime":490,"seo":491,"stem":492,"tags":493,"__hash__":496},"blogEn\u002Fblog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better.md","My Side Projects Failed Because I Kept Making Them Better",null,{"type":9,"value":426,"toc":483},[427,430,433,436,441,444,449,452,460,465,468,473,476],[12,428,429],{},"I have this tendency, both as a developer and in life. I love reorganising things, cataloguing, restructuring, and moving pieces around until everything feels ergonomic and clean. For a long time, I told myself this was a strength. What I didn’t see was that I was cleaning up before I’d even made a mess.",[12,431,432],{},"No system is truly perfect, bug-free, and ready for every future feature. But my fear of technical debt pushed me into overthinking the architecture of a simple project for weeks. The logic sounded reasonable: build a scalable foundation upfront and save yourself pain later. And I still believe structure matters, even for small and medium-sized systems.",[12,434,435],{},"But every time I finished a refactor and started implementing a new feature, I noticed ways the previous design could be improved for this specific case. So I changed the base classes. Then the database model. And soon, almost every new feature was somehow “blocked” by another refactor.",[12,437,438],{},[175,439,440],{},"At some point, I had to admit that something in my process was broken.",[12,442,443],{},"Not the tools. Not the language. Not the framework. The way I was working. I was optimising for correctness and elegance instead of progress. And progress is what actually exposes bad decisions. Without it, I was just arguing with imaginary future problems.",[12,445,446],{},[175,447,448],{},"So I changed the rules for myself.",[12,450,451],{},"I separated time for refactoring from time for delivery. Refactoring became a planned activity. Everything else was about shipping: new features, small improvements, fixing bugs, and closing todos.",[12,453,454,455,459],{},"I created a file called ",[456,457,458],"code",{},"TECHNICAL_DEBT.md",". Whenever something felt wrong or ugly, I wrote it down instead of fixing it immediately. What hurts? Why did it hurt? What would I change if I had the time? I scheduled a recurring time slot in my calendar to address it.",[12,461,462],{},[175,463,464],{},"That changed everything.",[12,466,467],{},"The work became calmer. Decisions became lighter. I stopped fighting myself while writing code. I could move forward without pretending that every choice had to be perfect. What took me longer to understand is why this pattern existed in the first place. I knew the theory. Everyone knows it. Overcomplicating a project at the beginning is a mistake. Premature abstraction is dangerous. You should let the system grow.",[12,469,470],{},[175,471,472],{},"But knowing that was not enough.",[12,474,475],{},"My perfectionism was doing something more toxic. It would not allow me to acknowledge technical debt at all. Writing something down as “imperfect” felt like admitting failure. Like proof that I was not a good developer. Not making progress on my projects kept me going further down this spiral.",[12,477,478,479,482],{},"What I am learning now is that good systems are not born clean. They become clean through use. Through mistakes. Through pressure from real users and real constraints. Finishing things turned out to be more rewarding than designing perfect systems. And accepting technical debt turned out to be a form of ",[175,480,481],{},"maturity",", not a failure.",{"title":115,"searchDepth":116,"depth":116,"links":484},[],"\u002Fimages\u002Fblog\u002Fside-projects-launch.avif","How perfectionism and premature refactoring stalled my side projects — and the rules that helped me start shipping again.",{},"\u002Fblog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better","2026-02-02","2 min read",{"title":423,"description":486},"blog\u002Fen\u002Fside-projects-failed-because-i-kept-making-them-better",[494,495],"Technical debt","Productivity","E11E8Gd7i2TGfjvl3JWoAfwUeUQJTxjyaQ5SaDmmsOQ",{"id":498,"title":499,"author":424,"body":500,"cover":519,"description":520,"extension":125,"featured":128,"meta":521,"navigation":128,"path":522,"publishedAt":523,"readingTime":524,"seo":525,"stem":526,"tags":527,"__hash__":531},"blogEn\u002Fblog\u002Fen\u002Fdoes-your-mvp-really-need-the-whole-cloud.md","Does Your MVP Really Need the Whole Cloud?",{"type":9,"value":501,"toc":517},[502,505,508,511,514],[12,503,504],{},"When we started building our project, we instinctively went all in on the cloud: Google Kubernetes Engine, managed services, an architecture ready for future scale. On paper, everything made sense—Kubernetes, high availability, automation. The problem was that at the time our app was just an MVP: a small number of users, a small team, and fast iterations.",[12,506,507],{},"We were hosting the frontend, backend, databases, and test environments. Nothing more. Yet we were paying for infrastructure as if we were handling traffic at the level of a mature product. Over time, it became clear that the cost and complexity were completely misaligned with the real needs of the project.",[12,509,510],{},"Instead of “optimising the cloud”, we took a step back. We migrated the infrastructure to a VPS. Kubernetes stayed. Order in deployments stayed too, thanks to GitOps and Argo CD. What disappeared was the entire layer of managed services that we didn’t actually need. On a single, understandable setup, we ran the frontend, backend, databases, and test environments.",[12,512,513],{},"The result was unambiguous: infrastructure costs dropped by roughly thirty times.",[12,515,516],{},"Beyond the business and cost arguments, there’s also something simply enjoyable about it. Setting up your own VPS, running Kubernetes on it, and hosting your frontend, backend, or databases gives you a real sense of control over the system. From time to time, it’s worth going back to these fundamentals, if only to remember what’s really happening under the hood. :)",{"title":115,"searchDepth":116,"depth":116,"links":518},[],"\u002Fimages\u002Fblog\u002Fmvp-cloud-vps.avif","Why moving an early-stage product from managed cloud services to a VPS cut infrastructure costs by roughly thirty times.",{},"\u002Fblog\u002Fen\u002Fdoes-your-mvp-really-need-the-whole-cloud","2026-01-30","1 min read",{"title":499,"description":520},"blog\u002Fen\u002Fdoes-your-mvp-really-need-the-whole-cloud",[528,529,530],"Infrastructure","MVP","Cloud","olfa7ZUAgxCW3GrjlhCpf5bnj-14agvGTMQs1UQsla4",1787647489238]