Support or Custom Work? A Decision Guide for Indie Devs

Treat a request as support when it helps a customer use the product you promised. Treat it as potential custom work when it asks you to deliver something beyond that promise. If it suggests a useful product improvement, evaluate it as a feature request before offering a paid project.

Start with what you sold: your plan description, documentation, onboarding commitments, and any customer-specific agreement. The amount of effort alone should not decide the category. A difficult bug can still be your responsibility; a small customization can still sit outside your support scope.

For solo developers and small SaaS teams, the practical goal is to identify what the customer needs, explain what is included, and make any additional commitment explicit.

A quick guide to classifying requests

The following is a recommended framework, not an industry-wide definition. Your existing commitments take priority.

| Request | Likely category | Next step | |---|---|---| | “How do I invite a teammate?” | Product support | Explain the existing workflow. | | “Invitations fail with an error.” | Suspected bug | Investigate the failure and communicate what you find. | | “Can invitations require manager approval?” | Feature request | Understand the need and assess product fit. | | “Build an approval flow connected to our internal system.” | Custom development | Assess feasibility and define a separate scope. | | “Configure every workspace for us.” | Implementation service | Check whether hands-on setup is included; scope it separately if needed. |

These are hypothetical examples. A managed onboarding plan might include workspace configuration, while a self-service plan might include guidance only.

Official policies illustrate this distinction. GitLab describes support around ensuring its product works as designed, while excluding requests to create custom scripts for its API. Atlassian’s support FAQ similarly distinguishes configuration guidance from development requests and professional services. These are examples of published boundaries, not policies every indie developer should copy. (GitLab Statement of Support, Atlassian Support FAQ)

Ask these questions before deciding

1. What outcome does the customer need?

A proposed solution can hide a simpler need.

Hypothetical example: A customer asks for a custom reporting integration because their accountant needs a monthly file. Your existing export may already provide the required data.

Ask what they need to accomplish, what they tried, and where the current workflow stops working. This gives you enough context to suggest an existing option or identify the actual gap.

2. Did you promise this behavior?

Review the relevant documentation, pricing page, and sales conversation.

If you advertised a supported integration and it fails under supported conditions, investigate it as a product issue. The presence of a third-party system does not, by itself, make the request custom work.

If your wording created a reasonable expectation that the feature existed, acknowledge the mismatch. Clarify the commitment before discussing a separate charge.

3. Is the customer asking for guidance or delivery?

There is a useful distinction between:

• Explaining how an existing import works.
• Investigating why a valid import fails.
• Cleaning, mapping, and importing the customer’s entire database.

The third request is an implementation service if it falls outside the purchased offering. It may involve no new product code, but it still requires a defined deliverable.

Likewise, showing an API example does not automatically commit you to building and maintaining the customer’s integration.

4. Is this a shared product need or a customer-specific requirement?

A request that fits your product direction may belong in your backlog. A workflow tied to one customer’s internal processes may suit a separate project.

Neither classification guarantees delivery. Recording a feature request means you will consider it; it does not establish a release date.

You can also decline custom work. A customer’s willingness to pay does not establish that you have the capacity or want the maintenance responsibility.

Handle uncertain cases with a bounded investigation

You will not always know whether the product or the customer’s setup is responsible.

Start with a small diagnostic step: request reproduction steps, inspect a relevant error, or compare the behavior with a documented example. Ask for only the information needed, with secrets and unnecessary personal data removed.

GitLab’s policy explicitly allows investigation of how its product interacts with customer code and infrastructure while placing limits on troubleshooting those external components. That is a useful model for separating diagnosis from taking ownership of an entire integration. (GitLab Statement of Support)

Hypothetical reply:

I’ll check whether our API is behaving as documented using the failing request. If the problem is in the integration code, I’ll explain what we found and where our support scope ends before discussing any additional work.

A diagnostic time limit can be an internal checkpoint. It should not automatically turn an unresolved product defect into a billable project.

Decide whether paid custom work is worth accepting

Once a request is clearly outside your included scope, assess the whole commitment.

Consider:

• Product fit: Does this support the direction you want to take?
• Delivery effort: Have you included discovery, communication, testing, and deployment?
• Maintenance: Who handles future compatibility changes and failures?
• Capacity: Which existing work would move to make room?
• Repeatability: Could this become a supported capability, or would it remain a separate obligation?

For uncertain requests, consider a separately scoped discovery phase before quoting implementation. Its deliverable could be a feasibility assessment and estimate, without promising the build.

Before starting, write down the deliverable, exclusions, customer dependencies, acceptance criteria, price, payment terms, and maintenance responsibility. Specify how changes to the scope will be approved.

Hypothetical example: “Build a CRM integration” is too broad to estimate confidently. “Send newly created contacts to one CRM account, with agreed field mapping and documented error handling” provides a clearer starting point. Historical imports and two-way updates would need separate decisions.

Explain the boundary with a useful next step

A clear reply should acknowledge the goal, identify the included help, and explain what the additional request involves.

Hypothetical reply for custom work:

You need the export to match your accounting system’s import format. I can help you generate the existing CSV export through support. Creating and maintaining a separate export format would be additional development. I can assess that separately, but I haven’t committed to a price or delivery date.

Hypothetical reply for a feature request:

The product does not currently support approval rules. I’ve recorded your use case for product planning. There is no committed release date, so please plan around the current workflow.

Hypothetical reply when declining:

I understand why you need this connection. I’m not taking on custom integrations at the moment. The available option is our documented API, though someone would need to build and maintain the connection.

Only offer options that actually exist. Avoid suggesting a workaround until you have checked whether it meets the customer’s essential requirements.

Put your support scope somewhere customers can find it

A short policy can cover:

• What support includes, such as usage guidance and product troubleshooting.
• What needs separate agreement, such as migrations or custom integrations.
• How feature requests are considered.
• Your support hours and expected initial response time.
• How you handle requests whose scope is initially unclear.

Keep response expectations separate from fix estimates. A promise to reply within one business day does not explain when an issue will be resolved.

If you use AI to draft support replies, review any statement about scope, pricing, refunds, or delivery dates yourself. A polished draft should reflect a decision you have already made.

References

• GitLab Statement of Support — product troubleshooting boundaries and custom-code exclusions.
• Atlassian Support FAQ — distinctions between support, development requests, and professional services.

Conclusion

Base the decision on what you promised and what the customer needs. Investigate suspected product failures, assess feature requests without implying delivery, and define additional services before committing. Clear boundaries make both the included help and any paid work easier to understand.