How do I handle a client who keeps adding requirements after we agreed on scope?

Use a formal change request process. When a new requirement comes in: stop, document it, estimate the additional time and cost, send a Change Request document, and wait for written approval before doing the work. "I'd love to add M-Pesa. That's a Change Request — additional KES 35,000 and 5 business days. I'll send the CR document now." Most clients accept this once they understand it is standard practice.

What should I do if I under-scoped a project and it is taking much longer than estimated?

Be transparent early, not late. As soon as you realize the scope was incorrect, send the client a note: "While building this, I discovered [X] is more complex than the initial scope estimated. This will take 5 additional days. I can absorb 2 of those days in goodwill, but the remaining 3 days will need a CR at our agreed rate." Clients respect early communication and resent last-minute surprises.

Should I scope payment testing into the project or is it assumed?

Always scope testing explicitly and describe what is included: "Unit tests for webhook handler (signature validation, idempotency, event routing). Integration test: full charge.success flow using Paystack test mode. Test coverage report included." This signals professionalism and prevents clients from asking "is there testing?" as a scope creep question later.

Scoping a Payment Integration Project Properly (Avoid Scope Creep)

Scoping a Payment Integration Project Properly

Scope a payment project by answering: 1) Which countries (each adds payment methods and compliance), 2) Which payment methods (card, M-Pesa, bank transfer, USSD, mobile money), 3) One-time or recurring, 4) Marketplace or direct, 5) Existing codebase or greenfield, 6) Who owns post-launch maintenance. Explicitly list exclusions in your proposal. Get written approval of the scope before starting.

Complete Discovery Checklist

Ask all of these before writing your quote:

Countries and currencies:

Which country or countries will customers pay from? (Nigeria? Kenya? Ghana? Multiple?)
Should the system handle multiple currencies or one primary currency?

Payment methods:

Card payments required? (most common, lowest complexity)
M-Pesa or mobile money required? (adds STK push integration, higher complexity)
Bank transfer or USSD required?
Does the business want to display all payment options or a preferred one first?

Payment model:

One-time purchase or recurring subscription?
If recurring: fixed billing date or anniversary of signup?
Free trial period? Proration for upgrades/downgrades?

Business model:

Is this a direct business (one seller, one buyer) or a marketplace (multiple vendors)?
If marketplace: does the platform need to split payments between vendors?
Does the business need to pay out to vendors or users?

Technical:

Existing codebase (what stack?) or new project?
Who owns and can access the production server after launch?
Does the business already have a Paystack account?

Common Scoping Mistakes

Assuming "one country" without confirming — "We're a Kenyan business but we have customers in Uganda and Tanzania." Now you need 3 country setups.
Not asking about recurring payments — "Oh, we also need monthly subscriptions" is the most common post-quote surprise.
Not asking about refunds — "Can customers request refunds from the app?" adds a refund management UI to the scope.
Assuming the client has a Paystack account — if they need to register and verify a business, that adds time.
Not asking who maintains it after launch — if they need you to maintain it, that is a retainer, not a one-off project.

Learn More

See the freelance proposal template for how to document your scope.

Sign up for the McTaba newsletter

Key Takeaways

✓Ask all discovery questions before writing a quote — missing one country or payment method changes the price significantly.
✓Explicitly list exclusions (what is NOT in scope) — this prevents scope creep.
✓Each additional country or payment method typically adds 30-50% to the project scope.
✓Get written approval of scope before starting work — email confirmation counts.
✓Use a change request process for anything outside the agreed scope.

Frequently Asked Questions

How do I handle a client who keeps adding requirements after we agreed on scope?: Use a formal change request process. When a new requirement comes in: stop, document it, estimate the additional time and cost, send a Change Request document, and wait for written approval before doing the work. "I'd love to add M-Pesa. That's a Change Request — additional KES 35,000 and 5 business days. I'll send the CR document now." Most clients accept this once they understand it is standard practice.
What should I do if I under-scoped a project and it is taking much longer than estimated?: Be transparent early, not late. As soon as you realize the scope was incorrect, send the client a note: "While building this, I discovered [X] is more complex than the initial scope estimated. This will take 5 additional days. I can absorb 2 of those days in goodwill, but the remaining 3 days will need a CR at our agreed rate." Clients respect early communication and resent last-minute surprises.
Should I scope payment testing into the project or is it assumed?: Always scope testing explicitly and describe what is included: "Unit tests for webhook handler (signature validation, idempotency, event routing). Integration test: full charge.success flow using Paystack test mode. Test coverage report included." This signals professionalism and prevents clients from asking "is there testing?" as a scope creep question later.

Ready to build real-world apps?

Join the McTaba Labs full-stack marathon (4 months full-time · 6 months part-time). Learn M-Pesa, USSD, and WhatsApp engineering while shipping 8 production apps.

Apply to the McTaba Marathon