This is both an amazing responsibility for you and a heavy responsibility. You will have the opportunity -- perhaps for the only time in your working life -- to not only have complete control over the technical solution, but if you are pro-active you may also have a say in the building the product, coming up with ideas for features.<p>On the downside, you won't have access to any senior technical personnel in the company to guide you or get you out of hot water. To mitigate this you will need to invest heavily in your continued technical education, which could mean buying learning materials or subscriptions to online courses and tutorials; at least, it means taking the time to do things right, to research thoroughly any new techniques or technologies you think the company needs.<p>While always striving to improve and to listen to your customers, you also need to have confidence in yourself and your technical decisions. It doesn't mean that you can't (or won't need to) compromise but it does mean projecting a professional image of yourself to your colleagues and customers. Obviously, the more you learn and the more experience you acquire, the more confidence you can bring to the role.<p>At the end of the day, like with any job, you should be willing to pack up and walk away if the situation becomes intolerable (as long as you leave things in a professional state).<p>But don't forget -- you are in the position right now that most programmers dream of. We started off wanting to just write programmes and build products for people who had the confidence in us to just let us do our thing; but then we found ourselves pidgeon-holed into roles predefined for us by IT departments. A complete programmer is like a complete painter, he should have a say in the product at all stages of its development. That means having the freedom to not just cut code or write tests, but to influence the design, to dream up new features, to have discussions about the marketing.<p>To an extent this role is YOURS to define. Have the courage to define it and to enjoy defining it. It might be the last time in your career that you get to do that, if you ever move on.
Have you asked whether you can bring in another developer at some point? Assuming your work is useful you don't want to support it 24/7 with no holidays? I work for an engineering company and came in as the 2nd developer. Over the years I've brought in many short and long term staff which has been a great learning opportunity. It takes a special sort of guy to be a one man team long term and is not for me.
I have an opposite question/concern - for many years I've been senior/lead/"irreplaceable"/etc.. person in many small shops (most of them were IT though). Now I'm thinking to get a job in BigCo - but I have that gut feeling/concern - I'll be just yet another cog in the wheel. How do you handle such feelings?
If I have to give you one advice it's to be or become good at explaining.<p>It's really hard to persuade your collaborators of your competencies, especially in the case of no-techs more if there is your boss or for a critical decision.<p>You'll become the king of metaphors!
My suggestion is not to do it. You will want to get back to IT industry, but it will be rather hard to do if you don't spend tons of spare time acquiring needed knowledge and skills, which is not so easy especially after 30. Source: worked for 7 years as the only developer in a non-IT company (oil and gas industry). The company had a sort of IT-department but 3 persons working there were busy reinstalling Windows, printers, PBXes, LAN, support and so on. I worked at R&D department with engineers and designers.
I've done this a couple times, and I would largely say don't do it since how terrible your environment becomes is largely dependent on things that are basically impossible to assess before starting.<p>The first time I was very junior but the programs that needed writing were mostly data crunching stuff or super simple rails apps that was simply a way to speed up the rest of the office. The company's core business was not in software and the fact that they could produce helpful code in house on demand was more of an added bonus. I also had experience with our domain so I was able to help out on non-coding issues when needed, as well as spot where a program could be helpful.<p>There were issues, though luckily I was able to work through with the management. The biggest is that as the sole dev in a non-dev shop you (assuming you show value after a couple projects) have a lot of people at the company giving you projects and this will likely outstrip your personal bandwidth. This can lead to feeling like you have n bosses where n is the population of the company minus one. The trick here is to get good at saying no as well as getting someone who is <i>actually</i> your boss and getting them to let you use them as a shield. The other problem is that you will probably run into estimate problems. Software estimates are frustratingly inaccurate when you're dealing with other devs, it gets much harder to explain to non-devs why "this little feature" is actually not so simple. The only thing that can help you here are your communication skills and other people's understanding/respect. Pad your estimates, if something <i>really</i> needs to get done wicked fast they'll let you know, otherwise just nicely surprise them getting it done early.<p>The second time I did it was terrible. The company was trying to develop a product that monitored sensor data and said it was going to expand the technical team. They also told me I could manage the technical project aspects myself since there weren't any other technical people.<p>Coworkers would pop in at least three times an hour to ask for help with Office or GoogleSomething or their phone, despite me reminding them that a) I'm not tech support, b) it's impossible to program if you're getting pulled away from your desk every 15-20 minutes. I was told that someone had met a programmer who could and so I should be able to.<p>My boss constantly was changing the requirements of the project as well as giving me "smaller projects" that weren't a part of the actual product. He would then be upset that despite working on Project F for two weeks we had made no progress on Project A for a whole two weeks! At one point the CEO demanded that I used a certain technology I had no experience using he got upset when I told him I had to devote some time to learning it.<p>Like any job these issues will largely depend on your coworkers and your boss(es), so YMMV but in my experience these issues are encouraged by the 1 techie vs n non-techies environment. Try to head off any of these issues early because if you let them get bad they will get intolerable.