Custom Solutions
When to build, buy or integrate, and how to get internal tools and portals right.
About the serviceBuild, buy or integrate: deciding on custom business software
Buy software for standard processes, integrate when your existing systems already hold the data, and build only where the process sets you apart. Companies of 20 to 200 people usually end up with a hybrid: buy the core system of record, then integrate or build the edges around it. Compare the options on 3 to 5 year total cost of ownership, not on the first invoice.
Start with the guideArticles and guides
Rust vs TypeScript: when to use eachTypeScript is the right default for web applications, APIs and business software because of its hiring pool, speed of change and ecosystem. Rust earns its higher cost in CPU-heavy paths, latency-critical services, embedded and edge work, and anywhere memory safety and predictable performance matter. The two are often combined, and this guide is for owners and technical leads at companies of 20 to 200 people deciding what to build in.Read Sentry vs PostHog: which one does your team need?Sentry is built for developers who find and fix errors and performance problems, and PostHog is built for product teams who need to understand user behavior through analytics, session replay, feature flags and experiments. Each has moved into the other's territory: PostHog now offers error tracking and Sentry offers session replay. This guide is for technical leads and product owners choosing monitoring for a web application, and for small teams deciding whether one tool is enough.Read SQL vs NoSQL: which database should a business application start with?Most business applications should start on a relational (SQL) database, usually PostgreSQL or MySQL, and add a NoSQL system only for a specific workload that needs it. Two old beliefs no longer hold: NoSQL products now offer transactions, and relational databases scale much further than their reputation suggests. This guide is for owners and operations leaders at companies of roughly 20 to 200 people who are approving a database choice.Read What is system design? The questions to ask before choosing an architectureSystem design is deciding a system's components, how data flows between them and which tradeoffs you accept, before anyone builds it. Ten questions on scale, data, uptime targets, integration, failure, security, team skills, cost, change and reversibility settle most of the choices. For a small team, the usual verdict is one well-organized application on one database, split into services only when a measured reason appears.Read Types of data analysis: what each one answers and which to start withThe four core types of data analysis are descriptive (what happened), diagnostic (why), predictive (what will happen) and prescriptive (what to do), with exploratory, inferential and causal analysis as three supporting methods. Most companies of roughly 20 to 200 people get more value from reliable descriptive and diagnostic reporting than from predictive models, so build those first. This guide is for finance, operations, sales and supply chain leaders.Read Types of databases: what each one is for, and which ones a business needsThere are nine common types of databases: relational, document, key-value, wide-column, graph, time-series, search, vector and columnar analytical. Each solves one kind of problem well, but most companies of 20 to 200 people need one relational database, often PostgreSQL, and a cache or a reporting store only when a measured problem appears. This guide is for business and technical leaders deciding what to add to their stack.Read 5 things to check before you ship a vibe-coded web or mobile appVibe coding is fine for prototypes and low-stakes internal tools, and risky once real customer or employee data, logins or money are involved. Before you ship, check five things: access rules and database row-level security, secrets in client code, dependencies nobody read, what the agent can do in production, and who owns the app after launch. This guide is for business owners and small teams building a web or mobile app with a coding agent.Read WebSockets vs SSE vs WebRTC: how to choose real-time updates for a business appUse server-sent events (SSE) when the server only needs to push updates to the screen, WebSockets when the browser and server both send messages continuously, and WebRTC for live audio and video between people. For most internal tools and portals, SSE or plain polling is enough, and WebSockets earn their extra moving parts only for chat, collaborative editing and two-way live data. This guide is for product owners and technical leads at companies of roughly 20 to 200 people.Read What separates a good developer from a bad one now that agents write the codeTyping code has become cheap, so the differences between developers now sit in judgment: framing the problem, designing the system, reviewing and testing what an agent produces, and owning the result in production. Good developers ask precise questions and verify the answers, while weak ones accept whatever compiles. This guide is for CTOs, IT leads and founders who hire or manage developers.Read What factors affect the cost of custom software developmentScope sets the cost of custom software: how many user roles it serves, how many systems it connects to, how much data must migrate and which security rules apply. Technology choices and hourly rates matter far less than most buyers expect. Budget for the years after launch as well, because hosting, support and maintenance continue for as long as the business depends on the software.Read Internal tools and customer portals: planning the first releaseThe first release of an internal tool or customer portal should cover one workflow for one group of users, end to end, rather than a thin version of everything. Decide roles, permissions and how people sign in before design starts, because those choices are expensive to retrofit. Then measure adoption against the work actually moving through the tool, not against logins.Read Off-the-shelf vs no-code vs custom software: when to use eachBuy off-the-shelf software for standard processes, use no-code or low-code for team tools, and build custom software when the process is specific to you or outgrows a platform. Govern every no-code app like any other business system, and test data volume and integration depth before committing, because that is where platforms stop. Companies of roughly 20 to 200 people usually end up using all three.Read SaaS subscription vs custom software: which costs less over five years?SaaS usually costs less over five years for standard processes with stable headcount, while custom software can win when per-seat fees grow and the process is specific to you. Model both with the same cost lines before deciding. This guide is for buyers at companies of roughly 20 to 200 people.Read How to write a software requirements brief (with a template) a development partner can useA software requirements brief is a two to four page decisions document stating the problem, the users, what the first release must do and how success is measured. It also covers how the process runs today, the systems and data involved, the constraints and who decides, and it leaves design to later. Written that way for a company of roughly 20 to 200 people, it produces comparable quotes, a realistic plan and far less rework.Read Technical debt in business systems: how to spot it, prioritize it and pay it downTechnical debt is the extra effort every future change costs because of shortcuts, age and neglect in the systems you already run. Leaders see it as slow changes, fragile integrations, spreadsheets holding processes together, one person nobody can replace, and software versions the vendor no longer supports. Pay it down in slices where it blocks work you actually plan to do rather than through a full rewrite, and expect AI projects to expose it fast.Read
Tools and checklists
Build, buy or integrate decision toolEight questions about one process. Get a recommendation to build, buy or integrate, the reasons behind it and what to check next.Open the tool AI project brief builderAnswer questions about the work, the systems it touches and what success looks like, and get a one-page brief you can share with any partner.Open the tool Build, buy or integrate: decision checklistA decision checklist for choosing whether to build custom software, buy an off-the-shelf product or integrate the business systems you already have.See the checklist
Other services
See how an idea becomes a working solution.
Explore how we scope, build and hand over AI projects, with clear decisions at each stage.