Working with Stackform

1. How projects work#

Every project follows roughly the same shape, regardless of size or complexity.

Discovery & scoping — Before any code is written, we align on exactly what is being built, why, and how. This results in a Scope of Work that defines the project clearly. Time spent here saves time everywhere else.

Development — Work happens in focused phases. You will receive updates as meaningful milestones are reached, not a daily stream of activity reports. No news during development is generally good news.

Review & testing — Before anything is handed over, it is tested. You will have a defined window to review the delivered work and raise any issues.

Handoff — Once the project is accepted and payment is complete, you receive full ownership of the codebase and all credentials. Nothing is withheld.

Post-launch — Every project includes a warranty period. After that, ongoing maintenance is available as needed. More on both of those below.

2. Communication#

How to reach me#

Email is preferred for anything that requires a record — questions, feedback, change requests, or concerns. For quick back-and-forth, a call or message works fine.

Response times#

Responses to non-urgent messages typically come within one business day. If something is genuinely urgent — meaning the production system is down or something is actively broken — say so clearly and it will be treated accordingly.

What “urgent” means#

Not everything that feels urgent is urgent. A feature request, a question about timeline, or feedback on a design is not urgent. A production system that is down and actively affecting your business is urgent. Treating everything as urgent means nothing gets treated as urgent.

Batching questions#

If you have multiple questions, send them together in one message rather than one at a time. This makes it much easier to respond thoroughly and keeps communication organized.

3. How to give good feedback#

Good feedback is specific. “This doesn’t look right” is hard to act on. “The booking confirmation screen is showing the wrong date format — it should show MM/DD/YYYY” is actionable immediately.

When something isn’t working the way you expected, the most helpful information is:

• What you did (the steps you took)
• What you expected to happen
• What actually happened
• A screenshot or screen recording if possible

The more clearly a problem is described, the faster it gets fixed. Vague feedback leads to back-and-forth that slows everything down.

4. What slows projects down#

Most delays in software projects come from the client side, not the developer side. That is not a criticism — it is just how projects work. Here is what causes the most friction:

Slow responses. Development often requires decisions or approvals before the next step can begin. A question that sits unanswered for a week can delay the project by more than a week once context is rebuilt.

Unclear or changing requirements. If the scope shifts mid-project, the timeline shifts with it. This is not always avoidable, but it should be a conscious decision with understood consequences, not something that happens accidentally through gradual additions.

Scope creep. Adding “just one more thing” repeatedly is how a 4-week project becomes a 12-week project. Every addition, however small, has a cost in time and attention. Changes to scope are handled through a formal change request — more on that in the agreement.

Withheld access. Projects that require third-party credentials, existing codebase access, or business information are blocked until those things are provided. The sooner access is granted, the sooner work begins.

5. Change requests#

A change request is any addition or modification to what was agreed in the Scope of Work. This includes new features, design changes, integrations not originally discussed, or any work that goes beyond what was defined.

Change requests are not a problem. They are a normal part of building software — requirements evolve, businesses change, and better ideas surface during development. The key is handling them deliberately.

Every change request is scoped, priced, and agreed to in writing before work begins. Nothing is added to a project silently. This protects both parties — you know what you are paying for, and the project does not quietly grow beyond what was budgeted.

6. Software maintenance — the car analogy#

This is the section most clients wish they had read sooner.

When you drive a new car off the lot, it is in perfect working condition. It starts, it drives, everything works exactly as it should.

But you still need to change the oil. Rotate the tires. Replace the brakes eventually. Get a tune-up. Not because the car was built badly — because that is simply what it means to own a car that runs in the real world.

Ignore that maintenance long enough, and small issues become big ones. The car that ran perfectly on day one starts having problems — not from any fault in the original build, but from normal wear and the passage of time.

Software works exactly the same way. Here is how the comparison breaks down point by point.

The initial investment#

Just like a car, a software application has an upfront cost. The more features and complexity, the more it costs — and the more it will require ongoing attention. A basic car gets you from A to B. A custom-built system with multiple integrations, user authentication, business logic, and third-party services is closer to the luxury end. More moving parts means more that can require attention over time.

The running costs#

A car needs fuel to run. Your software needs hosting — the servers that keep it online and serving users every day. This is a predictable, ongoing cost that exists separately from any maintenance work.

The maintenance costs#

This is the one that catches most clients off guard, and it should not.

If you drove a car for a year and then showed up at the dealership demanding free brake pads, the service manager would look at you like you had two heads. Everyone knows owning a car means budgeting for upkeep. Software is no different.

A typical custom application connects to anywhere from 6 to 30+ third-party services — payment processors, authentication providers, SMS services, hosting environments, and more. Each one is a potential point of change. When any of them updates their systems, your application may need to be updated too. That is not a flaw in the original work. It is the reality of building software that uses modern infrastructure.

Routine maintenance — keeping dependencies updated, patching security vulnerabilities, staying compatible with third-party services — is what keeps the car on the road.

Size and complexity matter#

Just as a commuter car costs less to maintain than a Hummer, the complexity of your application determines what ongoing maintenance looks like.

A custom-built application with multiple integrations, user authentication, and business-specific workflows sits firmly in the custom-built category. It will work — and it deserves the maintenance that keeps it that way.

7. What is a bug?#

A bug is a defect that prevents the application from doing something it was built to do.

Bugs are a normal and expected part of software. Every application has them — including software built by companies with thousands of engineers and billions of dollars. The goal is not zero bugs. The goal is an application that works, that does its job, and that gets fixed promptly when something goes wrong.

What you will receive is a finished, functional product that has been tested before handoff. If something in the agreed scope does not work at launch, it will be fixed under the warranty. What the warranty cannot cover is the future — new bugs introduced by changes outside the application, or issues that surface only after months of real-world use.

8. The warranty and ongoing support#

Every project includes a warranty period beginning at launch. During this window, any defect that prevents an agreed feature from working will be corrected at no charge.

After the warranty period ends, ongoing support is available at an hourly rate. This covers:

• Bugs that surface through continued use
• Compatibility updates when third-party services change
• Security patches and dependency updates
• Minor adjustments as the business evolves

There is no obligation to engage ongoing support. But clients who do tend to have fewer emergencies, lower long-term costs, and a system that stays healthy over time. The best time to fix a problem is before it becomes one.

9. What you are paying for#

When you hire Stackform, you are paying for:

• A working application, built to your requirements, delivered and verified
• Professional craftsmanship — clean, maintainable code built to last
• A warranty period where any launch defects are corrected at no cost
• A developer who knows your system and can support it over time

You are not paying for software that will never need attention again. No such thing exists — not from any developer, at any price.

10. When something feels wrong#

If something about the project feels off — the timeline, the communication, the quality of the work — say so. Directly and early. Small concerns that go unmentioned tend to become large ones.

The goal is a working product and a good working relationship. Both require honesty from both sides. There are no bad questions and no awkward conversations — only problems that fester because nobody said anything.