Important Things to Know to Build a Business and Solve Problems

The order that matters: problem, buyer, evidence, then build

Almost every early technology decision gets made in the wrong order. An owner or founder starts with the artifact — a website, an app, a dashboard, a robot — and works backwards toward a reason for it. The result is a well-built thing nobody needed, which is expensive precisely because nothing about it is broken.

The order that survives contact with customers is: name the problem, name the person who pays to fix it, gather evidence that they already spend money or hours on it today, and only then decide what to build. Every step skipped becomes a cost discovered later, at a worse exchange rate.

How to tell a real problem from an interesting one

Interesting problems are easy to find and generate polite enthusiasm. Real problems leave a paper trail. A candidate that fails two of the four tests below is usually worth abandoning, because dropping a problem costs nothing and building software for the wrong one costs everything.

1. Frequency. The problem happens daily or weekly rather than once a year. Rare problems get tolerated, not funded.
2. A cost the buyer can name. Ask what it costs today in hours, scrap, overtime, lost orders, or penalties. If nobody can produce a number, nobody has felt it enough to buy a fix.
3. An existing workaround. Someone already pays for a partial solution — a spreadsheet, a temp, an agency, a duplicate data-entry step. A workaround is proof of budget; a wish is not.
4. A person with authority. Identify the individual who can approve the spend, not the department. Enthusiasm from someone who cannot sign is the most common false positive in business.

Solve it manually before you automate it

The fastest way to learn whether a process deserves software is to run it by hand, badly, for a few weeks. Take the orders by phone. Do the scheduling in a spreadsheet. Send the report yourself every Friday morning. The manual version teaches you the exceptions, and the exceptions are where software projects overrun.

It is also the honest test of demand. A process nobody uses while it is free and manual will not become popular because it acquired a login screen.

Decide what to build, what to buy, and what to postpone

Most of what a young business needs already exists and costs less than anything custom. Reserve custom development for the part of the operation that is genuinely yours.

• Buy: hosting, email, payments, accounting, e-signature, scheduling, basic CRM, help desk. These are solved problems with mature products and no competitive advantage in rebuilding them.
• Build: the workflow that is your actual differentiator, the integration between two systems that refuse to talk to each other, or the tool that removes a step your competitors still perform.
• Postpone: anything whose value depends on customer volume you do not have yet. A recommendation engine with forty customers is a hobby.
• Replace later: outgrowing an off-the-shelf tool is a good problem. Being locked into custom software you cannot afford to maintain is a bad one.

What website and app work actually costs, and why quotes differ

There is no honest single price, because the word website covers four different products. In rising order of cost: a template-based brochure site is days of work; a custom-designed marketing site with a content system and original copy is weeks; a web application with user accounts, payments, and an admin area is months; a native mobile app for both iOS and Android with a backend behind it is the most expensive of the four, because you are paying to build and then maintain three codebases instead of one.

When two quotes for the same request differ by a factor of three, the usual explanation is not greed. One of them included discovery, content migration, testing, deployment, training, and a support window, and the other did not. Ask both vendors to price the same written scope line by line, then compare exclusions rather than totals.

Within any tier, the cost drivers are consistent:

• Number of distinct screens and user roles. An admin view is effectively a second product.
• Integrations. Every external system — payment processor, accounting package, ERP, shipping carrier, machine on the plant floor — adds design work, error handling, and a dependency you do not control.
• Accounts, permissions, and payments. Authentication and money both carry security and compliance work that is invisible on screen.
• Content. Fifteen pages of original copy and photography is often the real schedule bottleneck on a marketing site, and it is usually the client's homework.
• Design originality. Adapting a proven template costs a fraction of an original design system, and for many businesses it converts just as well.
• Regulatory scope. Health data, card data, accessibility requirements, or anything touching a regulated industry adds genuine work.
• Unknowns in what already exists. Connecting to an undocumented legacy system is the single most reliable source of overrun in this business.

How to evaluate a website, app, or software company

Every firm's site claims the same qualities, so ignore the adjectives and test for evidence instead.

Two or three serious candidates is the right number. Beyond that you cannot do this level of checking on any of them, which is how price quietly becomes the deciding factor.

These questions do most of the work:

• Show me two projects like mine, and tell me what went wrong on each. Every real project has a scar; a vendor who cannot name one is either new or not being straight with you.
• Who specifically will do the work, and what have they personally shipped? The sales engineer and the delivery engineer are frequently different people.
• What is the process from my brief to a working system, and where do I approve things? Look for a written scope, a design step you sign off on, testing, and a defined launch.
• What is not included in this price? The answer is the most informative sentence in any proposal.
• Who owns the code, the design files, the content, and the accounts when we are finished?
• What happens after launch — what does a small change cost, who answers, and how fast?
• If we part ways in a year, how does another team pick this up? A vendor who has thought about being replaced is usually worth keeping.

Own what you pay for

This is the section people wish they had read first. Ownership problems surface at the worst possible moment: when you want to change vendors and discover that you cannot.

None of this requires distrust. It requires writing down, in the agreement, who holds what — while everyone is still friendly.

• The domain name is registered to your business, in an account you control, with the registrar login in your possession — not in the agency's account.
• DNS, hosting, and certificates are billed to you. Vendors can have access; they should not have exclusive access.
• Source code lives in a repository you own, delivered in a state another developer can actually run: dependencies, environment notes, and deployment steps included.
• Analytics, ad accounts, business profiles, and app store developer accounts are created under your business identity from day one. Moving a published app between developer accounts later is painful and sometimes impossible.
• Design files, photography licenses, and copy are transferred or licensed to you in writing.
• Third-party licenses and their renewal costs are listed before you sign, not discovered at renewal.

Local, remote, or offshore

For software, physical proximity matters less than people expect and time-zone overlap matters more. Most web and app work happens on screens, so a competent team three states away is often indistinguishable from one across town. The genuine advantages of a nearby company are easier in-person discovery for complicated operations, someone who can stand on your plant floor when the requirements are physical, and a shorter path to accountability when something goes wrong.

Offshore development can be excellent value and is a legitimate option, with two costs to plan for: overlap hours, which decide how fast questions get answered, and specification burden, since less shared context means you must write more down. Whoever you hire, insist on the same evidence, ownership terms, and written scope.

If the project touches equipment, a facility, or a regulated process, weight local presence more heavily. If it is a marketing site or a straightforward application, weight portfolio and process more heavily than the address.

Red flags worth walking away from

Any one of these is a reason to slow down and ask harder questions:

• Guaranteed results inside someone else's system — a promised Google ranking, a guaranteed place in AI answers, a fixed number of leads. Nobody controls those.
• A fixed price quoted before anyone has asked what you already have, or a quote with no written scope at all.
• Refusal to hand over source code, or hosting only on a platform the vendor controls with no export path.
• Pressure to sign this week for a discount that expires.
• No questions about your customers, your current numbers, or the problem itself. A vendor who does not interrogate the brief will build exactly what you asked for and nothing you needed.
• A portfolio full of sites that no longer exist or were never launched.
• One person who is simultaneously salesperson, designer, developer, and support desk on a project that matters. That is a single point of failure, not a bargain.

After launch, problem-solving becomes a habit

Launch is where the information starts. Before it you had opinions; after it you have behavior.

1. Instrument one number that reflects the problem you set out to solve — booked jobs, quote turnaround, scrap rate, hours saved. Not traffic, unless traffic was the problem.
2. Change one thing per cycle. Two simultaneous changes make the result unattributable.
3. Set the window and write down beforehand what result would count as success. Deciding afterwards is how teams talk themselves into keeping things that do not work.
4. Talk to five users who did not build the thing. Ten minutes each, asking what they did last time rather than what they think of the design.
5. Retire what fails, and say so plainly. Killing a feature or a product without drama frees the one budget you cannot raise more of: attention.

Get the unglamorous things right

The failures that quietly kill small businesses are rarely dramatic. They are an expired domain, a backup nobody tested, an invoice nobody chased, a contractor with no signed scope, one email account holding every password.

Entity structure, contracts, tax treatment, and insurance are each worth an hour with an attorney and an accountant who work with businesses your size. That is the cheapest professional advice you will ever buy, and it is not advice a technology vendor should be giving you.

The basics worth setting up before you need them:

• Written scopes for every engagement, however small, including who owns the output.
• Backups someone has actually restored from, not merely configured.
• Passwords in a shared manager rather than in one person's browser or memory.
• One accountable person for renewals: domains, certificates, licenses, insurance.
• Books current enough that you know your real cost per customer before committing to a marketing spend.

Where Geek Engineering could fit

Geek Engineering is an engineering and technology company in Rosemont, Illinois, working with clients across the Chicago area and nationally. The work spans industrial automation and controls, electrical and mechanical design, custom software and system integration, IT services, applied AI, and technical consulting. That mix is unusual for a web shop and ordinary in our field, and it is exactly what determines whether we are a sensible call for you.

We could be a viable option when a problem crosses disciplines: software that has to talk to machines, a website or application that must connect to the systems already running your operation, data scattered across equipment and spreadsheets, or a process that is part mechanical, part electrical, and part code. We are also a reasonable fit if you want a small senior team you can talk to directly, with written scopes and defined ownership.

We are probably not the right choice if you want a purely visual brand site with heavy campaign creative, if you need a large team scaled up in weeks, or if the lowest available price is the deciding factor. Those are real needs, and specialists serve them better than we would.

If you are unsure, describe the problem rather than the solution — what happens today, what it costs, and what you would like to be true instead. We will say honestly whether it is our kind of work, and if it is not, what kind of company to look for. That answer is free, and useful even if you never hire us.