You can do many things to validate an idea without/before a cofounder, including building a prototype or having it built so you can test with users.
But launching an app (or website, or a device, or really any product) requires making a whole bunch of foundational decisions. If you can make these decisions and/or trust the people you hire (the dev shop, perhaps with assistance/cross-checking from technical advisors) to make them, then great.
1. Be clear in your mind whether you are dealing with a protoype (something that will be used to collect data then replaced) or a "beta" (the foundation of your product going forward). If it's a prototype, then go for it, knowing you will pay to rebuild it.
2. If it really is a beta, then build a list of the technical risks. If you cannot assess them get help who can. That help should have equity, or _at least_ should not be someone who is or might be paid to deliver the product, so that their interests and yours are aligned. In short a technical advisor, not a dev shop.
3. discuss the answers to/mitigation of those risks with your technical partners (which should include the paid developer/dev shop).
If your risks are moderate and seem to be reasonably contained, go forward: build and launch the beta. Startups always involve managing risk. But if you don't have confidence that you know what the risks you are taking are, or you see risks but lack confidence in how you have addressed them... well... maybe you do need a technical cofounder.
A couple of fictional examples to maybe make this a bit more real:
Amy wants to launch an iOS app for real estate agents to record notes after they show properties to a client.
Bea wants to launch an iOS and Android app that would overlay fantasy elements into everyday life via augmented reality, thus creating the next social gaming phenomenon, with embedded brand advertising for revenue. E.g., one day players might discover that VW Beetles, when viewed through their phones, "wake up" and ask for Diet Cokes; the player can get a reward by getting a friend to take a pic of a can of Diet Coke and "showing" it to the Beetle within the next 3 minutes.
Amy's risks? Well, notetaking is straightforward and understood with many apps that contain similar functionality. Dev shop estimates might be under $10K initially. Market size and frequency of use are both limited. Inconsistent cell service may have to be managed but iCloud helps with that. Marketing/making big deals could be timed for when user feedback shows the app is ready. In short, go for it.
Bea's risks? Multiple sensor usage (camera, maybe geolocation, voice, etc), image recognition and maybe 3d image composition, virtual reality user experience, marketers' expectations for user experience quality and embedding of brand assets, cross-platform development with lots of shared back-end services, real-time interactions with friends & the environment, "fun factor" requiring lots of iteration/experimentation/polish on user experience, and the big one: scale. For the social model (and eyeball monetization generally) to work you need lots of customers, and you are certainly hoping that you will be a "gaming craze" and get lots of users interacting in a short period of time. And if you do get a buzz it may not be on your intended schedule. Probably investment for a demo alone would be six figures; a beta game would be seven figures. In short: build that strong technical cofounding team now.
I hope this has been an entertaining look at the question. Both of the above startup ideas are freely available for anyone who wants to fail, by the way :).