When "Just One Small Thing" Isn't So Small 🔄

We get it - as your project develops, you'll have new ideas, see opportunities for improvement, or realize something could work better than originally planned. That's totally normal and often leads to better results! Here's how we handle changes professionally while keeping your project on track.

Why Changes Aren't Always "Quick"

The Ripple Effect What looks like a simple change often affects multiple parts of your website:

  • Changing a button color might seem quick, but we need to check if it affects accessibility, update any related styles, test on different devices, and make sure it doesn't conflict with other elements

  • Adding a field to a form means updating the database, modifying the processing code, testing all form submissions, updating any confirmation emails, and checking how it displays on mobile

  • Moving a section might require restructuring the layout, updating responsive design, adjusting other content to fit, and retesting the entire page

Quality Takes Time We don't just make changes - we make changes properly:

  • Testing everything to make sure the change doesn't break something else

  • Mobile responsiveness verification

  • Performance impact assessment

  • Documentation updates so you know how the new feature works

Types of Changes & How We Handle Them

1. Bug Fixes (Usually Free During Warranty)

What Qualifies:

  • Features that don't work as originally agreed

  • Broken functionality that worked before

  • Code errors that prevent proper operation

  • Display issues that don't match the approved design

Our Process:

  • Immediate acknowledgment of the bug report

  • Quick assessment to confirm it's a bug vs. a change request

  • Fix within warranty terms (90 days for custom work)

  • Testing to ensure the fix doesn't create new problems

2. Clarifications & Minor Adjustments (Often Free)

What Qualifies:

  • Small tweaks to match the original vision better

  • Minor wording changes or content adjustments

  • Small spacing or alignment improvements

  • Color adjustments within the approved design

Our Approach:

  • Quick evaluation to determine scope

  • Include in current work when it's truly minor

  • Brief explanation if it's actually bigger than it appears

3. Scope Changes (Always Discussed First)

What Qualifies:

  • New features not in the original plan

  • Significant design modifications

  • Additional pages or functionality

  • Integration with new third-party services

  • Changes that affect project timeline significantly

Our Process:

  • Stop current work to evaluate the change

  • Written assessment of impact on timeline and budget

  • Your approval required before we proceed

  • Updated timeline and cost estimate provided

The Change Request Process

Step 1: Submit Your Request

Email us at contact@darn.pro with:

  • Clear description of what you want changed

  • Why you want the change (helps us suggest the best approach)

  • How urgent it is for your timeline

  • Any examples or references that help explain your vision

Step 2: We Assess & Respond

Within 24 hours, we'll tell you:

  • Whether it's a bug fix (covered under warranty) or a change request

  • Estimated time and cost for the change

  • Impact on current timeline and delivery dates

  • Any technical considerations you should know about

Step 3: You Decide

Your options:

  • Approve the change and we proceed with updated timeline/budget

  • Postpone the change until after current project completion

  • Modify the request based on our feedback

  • Skip the change entirely

Step 4: We Execute

Once approved:

  • Written confirmation of the change scope and cost

  • Updated project timeline shared with you

  • Change implemented with same quality standards as original work

  • Testing and review before marking it complete

Common Change Request Scenarios

"Can we just move this section up?"

Why it's not "just" moving: Might affect responsive design, content flow, user experience, and require testing across devices.

Typical time: 15-30 minutes including testing

"Can we add social media icons?"

What's involved: Sourcing/creating icons, determining placement, coding the links, styling for different screen sizes, testing functionality.

Typical time: 20-60 minutes depending on design integration

"Can we change the contact form?"

Behind the scenes: Form field updates, database changes, email template modifications, spam protection updates, testing all form scenarios.

Typical time: 30-60 minutes depending on complexity

"Just make the logo bigger"

Considerations: Mobile responsiveness, header layout, navigation impact, visual balance, load time effects.

Typical time: 15-30 minutes including cross-device testing

Managing Changes During Different Project Phases

During Initial Development

  • Easier to implement when building from scratch

  • Less testing required since everything's in development

  • Minimal disruption to overall timeline

  • More flexibility in approach and implementation

During Final Testing Phase

  • More complex because other elements are finalized

  • Potential timeline impact if changes are significant

  • Careful coordination needed with other project elements

After Launch (During 90-Day Warranty)

  • Bug fixes covered under warranty terms

  • New features billed as change requests

  • Priority given to functionality issues

  • Stability considered - we're careful not to break working features

During Ongoing Support

  • Change requests billed at regular rates

  • Emergency changes available at premium rates if needed

  • Maintenance contract clients get priority scheduling

  • Planning encouraged to batch changes efficiently

Preventing Change Request Chaos

Clear Initial Planning

  • Detailed specifications during project planning phase

  • Feature lists that everyone agrees on upfront

  • Regular check-ins during development to catch issues early

Smart Communication

  • Regular updates that let you see progress and spot potential changes early

  • Clear explanation of how features will work

  • Proactive suggestions when we see potential improvements

Change Budgeting

  • Set aside 10-20% of project budget for likely changes

  • Plan for evolution - websites often improve during development

  • Prioritize changes - do the most important ones first

  • Consider future phases - some changes might work better as post-launch improvements

What We Promise About Changes

Transparent Assessment

  • Honest time estimates based on real experience

  • Clear explanation of why changes take the time they do

  • No surprise billing - you approve costs before we start work

  • Alternative suggestions when we can achieve your goal more efficiently

Fair Pricing

  • Same hourly rates as original development work

  • No "change order premiums" or administrative fees

  • Detailed time tracking so you see exactly what you're paying for

  • Efficient implementation - we don't milk changes for extra hours

Quality Maintained

  • Same testing standards for changes as original work

  • Integration checking to ensure changes work with existing features

  • Documentation updates when changes affect how you use the site

  • Warranty coverage for change work just like original development

Tips for Successful Change Requests

Be Specific

  • "Make the button more prominent" is vague

  • "Make the contact button larger and change it from blue to orange" is actionable

Explain the Goal

  • Why you want the change helps us suggest the best approach

  • What problem you're trying to solve might have multiple solutions

  • How users should benefit guides our implementation decisions

Consider Timing

  • During development is usually more efficient than after launch

  • Batch related changes rather than requesting them one at a time

  • Plan ahead when possible - last-minute changes are stressful for everyone

Stay Flexible

  • We might suggest alternatives that achieve your goal more efficiently

  • Some changes work better as future phases rather than current project additions

  • Technical limitations sometimes require creative solutions

When to Push Back (Nicely)

We'll always try to accommodate your requests, but sometimes we'll suggest alternatives:

If the Change Hurts Performance

"This change would slow down your site significantly. Here are some alternatives that achieve a similar result..."

If the Change Creates Security Risks

"This approach could create vulnerabilities. Let's find a safer way to accomplish what you need..."

If the Change Conflicts with Best Practices

"This might hurt your SEO/accessibility/user experience. Here's what we'd recommend instead..."

If the Change Creates Maintenance Problems

"This approach would require manual updates every time WordPress updates. Here's a more sustainable solution..."

The Bottom Line:
Changes are normal and often make projects better! Our process ensures that changes get implemented professionally without derailing your project timeline or budget.

Got a Change Request?
Email contact@darn.pro with the details, and we'll get back to you within 24 hours with an assessment and options.

Because the best projects evolve during development - we just want to manage that evolution smartly.