There are ways of improving quality without QA. QA does not improve quality, it detects the lack of it. All quality is essentially a direct output of development and product specification.
You can improve quality in several ways,
1) Improve the quality of the specifications. Most business logic bugs are due to mis understandings between what was implemented and what should be the case. You can use methodologies such as Agile that force smaller break downs of project specification coupled by tight regular acceptance checks. Have clear acceptance criteria will help with that. When I say clear acceptance criteria, I mean define the problem and the desired outcome so well that any developer becomes the expert at that piece of the problem during the time he's working at it.
2) Invest in development practices that ensure understand ability. Another source of bugs is misunderstanding between developers or misunderstanding of code. Have a clear development framework, and clear separation of logic. A common problem I see new developers do is having business logic mixed in with adapter and plumbing logic. This makes code confusing to read and leads to a high number of mistakes when working in large teams.
3) Invest time in planning and architecting the solution. Generally people hate meetings, yet engineering is mostly about design and architecture. During hackathons, I've seen entire games put together in 3 days, which proves that very little time in engineering is spent on actual coding. It's not uncommon for a high performing team to be in workshops and meetings for 3 days for every 1 day of coding. There's very little lines of text that goes into coding any particular feature, and more time spent on research and trying things out. Investing the time upfront to getting all the players on the same page, and debating out solutions before a single line of code is written improves quality many times over.
4) Put various quality enforcement baked into the process. Automated tests. Static code analysis. Code coverage. Cyclomatic complexity checks. Security Scans. Code review.
Another way which sounds unattractive is to admit up front to the user community that they are they are using non tested software. If the outcome is not critical or important perhaps the price could be reduced or made free until the bugs are worked out. Users may prefer partially working products at low cost rather than nothing. I have used software, hardware, games that were unique and not tested an very buggy. But the idea was so unique that I didn't mind. Also the products were improved quickly. I was in the role of the customer in an Agile process and it was OK.
When in Florida, Don't Tampa with the code. I made this up.