I was a hacker edged into the biz/sales role (we had 2 other, stronger tech guys on the team). So this is my perspective from watching (and building pieces of) the tech over 3ish years.
Code quality matters. We did enterprise sales across several products, and it got to the point where making minor tweaks to the older products to close a sale was a complete nightmare.
You probably don't need to rewrite it. In most cases I've seen, re-writing (e.g. switching technologies) is some sort of pathological denial about delaying the admission that nobody wants the product.
The importance of scalability depends on your channel. We spent a lot of time building in scalability, which was important for an advertising company (we couldn't close sales w/out scale guarantees), but might not be important for a word-of-mouth app.
Build an admin dashboard. A good one. You're losing countless weeks if the CTO is a bottleneck for deploys and minor database tweaks.
I wish we'd used a modern web framework. I didn't write any of the server side code, but our development felt particularly sluggish there.
Check for plugins and tools before writing it. Some of the stuff we wrote from scratch was 2x commenting systems, 2x moderation systems, 3x analytics & charting systems, and a widget sharing wrapper. Writing some of those in-house was correct, but we did it somewhat compulsively.
Think long-term. We wrote some widgets in Flash, then switched to Flex because development was slow. But for our ultimate vision, we needed <10kb widget sizes, so we had to switch back to Flash a year later. Since the core of our product was in that widget's UI, it was a non-trivial rewrite.
Write a stupid version of the UI first. A major UI overhaul delayed the rest of a key deploy for ~3 months. Starting with a quick v1 UI which copied twitter would have allowed the UI/UX guys to do things properly without the server team screaming at them every day.
Shipping makes people happy. If you have an API, get people writing (& launching) little apps which use it. Have them own those apps personally and keep them on their personal githubs/portfolios. If you are playing in an industry, encourage people to make 1-2 day apps, separate from your product but wthin the same space. You'll stumble across some gold.
+1 for "before writing it" - it's easy to end up wasting time building stuff which isn't a differentiator to your business, if it's not a differentiator for you than see if you can use something off-the-shelf.
This applies for the operational side of the business as well, there's no reason you should be running your own mail server, etc. today. If you're not doing it in some unique way, figure out it you can get someone else to do it for you.
Code quality matters. We did enterprise sales across several products, and it got to the point where making minor tweaks to the older products to close a sale was a complete nightmare.
You probably don't need to rewrite it. In most cases I've seen, re-writing (e.g. switching technologies) is some sort of pathological denial about delaying the admission that nobody wants the product.
The importance of scalability depends on your channel. We spent a lot of time building in scalability, which was important for an advertising company (we couldn't close sales w/out scale guarantees), but might not be important for a word-of-mouth app.
Build an admin dashboard. A good one. You're losing countless weeks if the CTO is a bottleneck for deploys and minor database tweaks.
I wish we'd used a modern web framework. I didn't write any of the server side code, but our development felt particularly sluggish there.
Check for plugins and tools before writing it. Some of the stuff we wrote from scratch was 2x commenting systems, 2x moderation systems, 3x analytics & charting systems, and a widget sharing wrapper. Writing some of those in-house was correct, but we did it somewhat compulsively.
Think long-term. We wrote some widgets in Flash, then switched to Flex because development was slow. But for our ultimate vision, we needed <10kb widget sizes, so we had to switch back to Flash a year later. Since the core of our product was in that widget's UI, it was a non-trivial rewrite.
Write a stupid version of the UI first. A major UI overhaul delayed the rest of a key deploy for ~3 months. Starting with a quick v1 UI which copied twitter would have allowed the UI/UX guys to do things properly without the server team screaming at them every day.
Shipping makes people happy. If you have an API, get people writing (& launching) little apps which use it. Have them own those apps personally and keep them on their personal githubs/portfolios. If you are playing in an industry, encourage people to make 1-2 day apps, separate from your product but wthin the same space. You'll stumble across some gold.