208 karma · joined March 1, 2013
That said, I do like using a calendar approach for tasks. I've previously used TeuxDeux successfully - it's basically just a todo list per day and it makes it easy to plan things ahead of time and move them around as reality bites and you need to move it to a later date.
One thing I'd say is to take anything you hear from any given indiviual with a pinch of salt. People love to give advice and will often sound authoritative about subjects they have no expertise in. Everyone's experience will also be different, and people tend to give advice based on their own anecdotes which may be completely irrelevant to you. You see it all the time where people try to mimic the actions of others who have had success, only for them to fail miserably trying to follow the same path. These conversations can shed interesting ideas and thoughts, but make sure you don't treat them as gospel and instead use them to help figure out your own view.
Jack’s post acknowledges what most of the community felt for years - the biggest mistake was alienating the developer community while trying to chase commercial success. The irony is that ExtJS and Sencha could have been hugely successful commercially if they had approached it differently. Instead the only people building on it were usually people working in large corporations, and even those would never use it for hobby projects outside of work due to minimum purchase of multiple seats to use the non GPL license.
I look back fondly on my time using ExtJS as a developer. They had some of the smartest engineers around working on the framework, a great community in spite of Sencha’s best efforts and I learned a metric ton along the way. Who knows where it would be today if it all went a little differently!
* $15.826 billion in US/Canada
* $8.357 billion in Europe
* $6.244 billion in Asia/Pacific
* $3.244 billion in Rest of the World
While many of us here would prefer the idea of owning and licensing software in perpetuity, the reality is that most users don't care and are typically more price sensitive to the point that they will prefer to pay a small amount monthly than pay a large lump sum once. The monthly pricing mechanism also provides a safety net, as you can stop paying at any time if a product no longer provides utility or if you straight up can't afford it.
At the other end of the spectrum, SaaS works very well for business. Larger companies always paid recurring fees to software vendors anyway - typically as support and maintenance, because they need SLAs and commitments that ensure continuity of being able to use the software in a reliable manner. In the past, these were usually a recurring add-on that was paired up with a major up-front cost. Today, it's reversed where you now might pay a small once-off cost for implementation or delivery, but the bulk of the pricing is weaved into the recurring subscription cost. This works better for most businesses.
Also, a much higher percentage of software makers these days are doing so on the back of venture funding. The north star metric for most venture-backed companies is annual recurring revenue, so a subscription model is almost the default when it comes to a venture-backed startup. When a company is focused on rapid and high scale growth, having to start every year at zero makes it significantly more difficult to succeed.
Workvivo is an employee communications platform, designed to bring your workplace culture to life. Think of it as a social network, intranet and employee app solution all streamlined into a modern digital employee experience. Our mission is to help companies drive engagement in their workforce and better align employees with the goals and values of the organisation.
We're based in Cork, Ireland but are working entirely remotely since the pandemic and hiring internationally for most roles. Our team of 30 are currently spread across Ireland and the Bay Area. We raised a $16m Series A earlier this year, and are currently hiring across product management, engineering, marketing, customer experience and sales. For product and engineering roles we are looking for mid to senior level experience at this time.
Tech Stack: AWS, Laravel, PHP, MySQL, Redis, Elasticsearch, React, React Native, GitHub
Reach out to me directly if interested - my email is my first name at workvivo.com.
In Ireland you pay 20% income tax on the first €35,300, and 40% on income above this amount (if you are a single person, there are different cut-offs for married people and one-parent families).
You also pay an additional Universal Social Charge on all income over €13,000 - between 2-8% depending on your income level, or 11% for self-employed income over €100,000. Add on pay related social insurance (PRSI) of 4% too.
In your example - if I prefer Domino's to Pizza Hut, what do I go to? I need to go to pizza.new to discover that it's linked to Pizza Hut and then try to figure out what Domino's action might be. In the end I'll just end up going to the main site instead. I think the value of this concept is completely nullified by binding the actions/domains to specific providers.
For me, the better implementation would be where for each "action" there are numerous providers and at a user level you could define which one you want to use. So user A goes to repo.new and gets redirected to GitHub, user B goes to GitLab, user C to Bitbucket and so on. The first time you go to the action you're prompted to select which service you want to use by default and from then on you go straight through.
For me personally the perfect app just needs to stay out of my way most of the time. My lists are typically what I want to get done today or at most this week - I don't need reminders or nagging, repeated items, subtasks, fancy formatting or complex UIs. Just a list that I can bring up quickly and hide even more quickly.
The one thing that's missing for me right now (and I can see you're already on the case) is an iOS app with iCloud sync. When that's available I could definitely see myself replacing Apple Notes with this.
On a side note (sorry, couldn't help it) I was browsing through the other apps you have listed in the footer and some really nice looking apps in there! Nice work! Definitely going to give TeaCode, ScreenFocus and Expressions a try.
Something that is typically much less trivial is user provisioning from an identity provider. Most companies availing of SSO will require an automated user provisioning process also be in place. While the SCIM standard is pretty good, and support for it is getting better, implementations of it in identity providers are quite varied and often incomplete, not to mention poorly documented. Companies often also need to provision data that is not stored in the identity provider, so you can imagine the challenge in providing alternative solutions to make that work.
As others have already pointed out, it’s far more likely however that vendors see the requirement for SSO as a signal that a company is larger and falls more in the “enterprise” tier of pricing, allowing them to instantly provide something of value at a higher pricing point. SSO is treated much the same as things like premium support and SLAs - you charge extra because the customers who want it can afford to pay for it.
One bit of advice I’d offer is to know going in that software development is likely to be the least of your problems when running a software company - especially for a software engineer. Your real challenges lie in sales, marketing and customer relations. If you’re not successful at these aspects of the business, it doesn’t matter how good or bad your product or code is.
https://news.ycombinator.com/item?id=15365797
Edit: It certainly looks as though the entire team was let go based on the LinkedIn post you linked to in your edit.
Sencha's biggest failure was not building developer mindshare. If they wanted to sell commercial widgets, they should have done just that - their grid was pretty amazing and is probably the feature that led most people to discovering ExtJS in the first place. Instead they tried to sell an entire framework, with an entirely custom approach to building software. For that model to succeed, they should have made the framework itself free on a liberal open source license, and focused harder on selling services, extensions and tools around it. That way, it would have been embraced by more developers, widened the talent pool and encouraged their big corporate customers to expand the scope of its use in their companies.
This day was always going to come, however. Sencha's commercial side has always had a habit of making bad decisions, and have always focused on attracting companies rather than developers. This led to initial success on the enterprise side of things - they had a large percentage of the Fortune 100 on their customer books. The problem was that developers didn't use ExtJS outside of the enterprise setting. This was primarily due to the decision to use GPL for the open source license and later to completely alienate individual developers by introducing a 5-developer minimum purchase for commercial licenses. Although I was highly competent with ExtJS and Sencha Touch, I never used it on any side projects mainly because of these issues. All of this meant that when it came to hiring developers with ExtJS experience, it was always a struggle, and I believe it is for this reason that it never took off outside of the big corporates.
http://existdissolve.com/2017/09/a-fond-farewell-to-sencha/ https://mitchellsimoens.com/next-chapter-in-2017/ https://twitter.com/dongryphon/status/911278681611370496 https://twitter.com/AnimalNige/status/911152490380451840 https://twitter.com/evantrimboli/status/910988537763323904 https://twitter.com/elmasse/status/906243331541360640 https://twitter.com/LemmonsGrab/status/911703530716618752 https://www.glassdoor.com/Reviews/Employee-Review-Sencha-RVW...
The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.
As for determining if she is the right person professionally, I'd make a list of all of the things that...
1. You suck at
2. You hate doing
...that will be necessary to succeed. In a perfect world, she will excel at many/all of these things and love doing them - allowing you to divide the workload and each focus on your strengths. Don't take her word for it - find out, test her, check references, do whatever you have to do to be comfortable that she is the right person.
Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.
Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".
Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.
Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.
I've written a little more about this on Medium - https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...
As for signing an NDA, I've found that often people who require them are pedantic about unimportant things and difficult to work with, so unless there is a very good reason they'd need one I'd be very cautious about getting involved.