Your vision. You're in control.
My first priority is the correctness/usefulness of the software. I want my code to solve your problems as quickly as possible so you can live your life. I will meet with you often (if desired) to make sure you are happy with the product as it evolves to cover all the use cases.
Conveniently, I am a single person. Once we establish trust, you need not worry about dealing with anyone else. You will never be wrestling with a customer service department if issues arise. You can explore the rest of my website if you wish to learn more about me and my values.
As the client and developer, we will likely hold different pieces of the puzzle. I have written enough software to develop strong opinions about application design and how to make software as capable as possible with minimal negative impacts to performance and user-friendliness. If I spot a potential improvement, such as two separate 'features' that might be merged into a single elegant solution, I will propose it to you with a detailed explanation. You always make the final decision!
Clear error feedback, complete documentation, and open standards. No lock-in.
More often than not, when a user clicks a button to perform a 'single' action in a cloud-based application, that action really consists of multiple independent steps under-the-hood. Those steps can succeed/fail independently of one another and leave the action in a partially-completed state.
Many applications just ignore the nuance of such situations and surface a generic error like "Oops, something went wrong." Behind the scenes, they typically do log the full context and error details somewhere on the server. This may be due to laziness, lack of time, or simply a new developer who has not yet thought of better solutions. Sadly, companies are often incentivized to leave code like this alone so that they make more money off of customer support because only they know how to investigate and fix issues.
I don't believe an application is complete until every fixable error the code can encounter has been carefully considered and documented, and context-aware measures have been taken. In some situations, it might make sense for the software to try and fix an error automatically, such as when part of a large file upload failed because network connectivity dipped for a few minutes. Other times, an error might require human intervention. Let's say I built a forum application so employees can answer customer questions. Dexter and Rita, two employees, submit a response to the same customer question at almost exactly the same time. Rita's answer makes it to the database first. I would design the application so it alerts Dexter that Rita just answered the question, refresh the interface so he can see Rita's answer in his browser, and give him the chance to edit his answer, still submit it as-is, or abandon his answer because Rita's answer already covered everything.
In addition to excellent error handling and documentation, I strongly believe in open standards. Imagine if Microsoft Edge, Google Chrome, and Mozilla Firefox did not support the same image formats. What if you could only make your website correctly display images in one browser. That would be ridiculous. Open standards make applications more interoperable and therefore more useful.
I want you to continue paying me because you loved my work and want me to build more things for you. Not so I can treat symptoms over and over because my software is a bug-laden black box.
Exceptional performance. No jank.
Every action you take within the software should feel snappy. If you undertake a large task that cannot be completed instantly, the user interface will still update instantly to let you know that the system is working on it, with detailed feedback as progress is made. No more stressing when you click a button and nothing appears to happen.
No visual overlap of buttons and other UI elements. No weird scroll bars. No crashes. Period.
Accessibility for the disabled. And the abled.
You may have heard the term "accessibility" used in the context of software before. It's a blanket term covering efforts like making applications compatible with screen readers for blind people, or disabling flashy animations for people who have epilepsy or get motion sick easily.
I take it further. Software should be visually clean and easy to navigate regardless of diagnosed disabilities. Excessive use of animations can easily become annoying even for the abled. Text should be as made as legible as it possibly can be. The widget hierarchy in an application should be as obvious as it possibly can be. Lastly, applications should adapt gracefully when using browser zoom capabilities or accessibility tools in your operating system.
Security, done thoughtfully. No more frustrated users.
Security is a big thing in the software industry these days. No one wants to be the victim of ransomware or other attacks. That said, security features are often marketed at people using a large dose of FUD (Fear, Uncertainty, Doubt). I myself am sick of being forced to use 2FA for very low-stakes software. It adds an extra bit of hassle everytime I need to authenticate, and companies will often try to leverage such features as a reason to obtain more personal information like my phone number. Worse yet, most (maybe all) security mechanisms only help if used correctly.
I worked at a security startup for over 7 years. Almost all of my programming experience has been obtained hands-on in an environment where ultimate security is the #1 priority. I am cognizant of security/usability trade-offs, and able to implement serious measures when they do matter.
Interested in my services? Quotes are free.
You can use the form below to reach me. Please be as detailed as possible up-front about what you want to accomplish, as that will expedite our negotiations. It is okay if you are unsure about what it will take to accomplish your vision—that is where I come in.