Below are some questions I get asked regularly about my web development consulting services. For more information about my services, take a look at my Hire Me page.
It depends. I'm a web application development consultant. What that means is that I develop applications on the web for my clients. Applications are different from say, a marketing site or a blog, in that they have highly custom features and behavior specific to your business.
If you're building a custom web application, I'm probably a good candidate for your project. But if you want a new marketing site, blog, content site, IT deployment, or another implementation of an off-the-shelf solution, you'll be better suited going elsewhere. I am happy to refer you to someone who can help you though. Get in touch and let me know what you're looking for.
I don't have one. I stopped billing by the hour because it creates poor incentives for everyone involved. Rather than measure progress in terms of business outcomes, hourly billing causes us to measure our progress in terms of deliverables. We had a meeting, I sent you an email, I developed such-and-such a feature, etc. These things are necessary in the pursuit of your business goals, but they don't represent the true value of custom software to your business.
Instead, I bill weekly. Rather than handing you an invoice that lists all the email I sent, the meetings I had, and the code I wrote, you'll get an invoice that lists the specific value I delivered to your business this week. My weekly rate varies from client to client based on need, and I like to make sure it's an equitable arrangement for both of us.
It's my goal to ensure the application we build is an asset to your business for years into the future. That's why I focus on technologies with a long track record of community support and success in the marketplace.
Right now, my toolbelt consists mainly of the Ruby on Rails web framework and the React UI library. Both of these technologies have been used in production for years, are proven to be maintainable and scalable, and are easy to transfer to new development teams without much onboarding.
Over the years I've honed my approach to software development to be asynchronous, iterative, and agile.
By asynchronous I mean favoring online discussions over meetings, Basecamp over Slack, and working by the whims of creativity rather than on a set schedule. I've found that by cultivating vast swaths of uninterrupted time, I build better software faster. That doesn't mean it's not critical to have face-to-face interactions when necessary, but I like to make them the exception rather than the rule.
By iterative, I mean that I'm going to deliver you working software at least once per week, sometimes once per day. It's my responsibility to deliver you excellent software, and it's your responsibility to make sure it meets your needs as I deliver it. By working in such an iterative fashion we'll eliminate the possibility that we've veered off course. You'll always be in control.
And by agile, I mean that I'll use tools and best practices which ensure we can change course at a moment's notice should the need arise. Business is not static, and neither are your technology needs.
Send me a message and ask away!